MSDN Magazine - December 2008 - (Page 42)

for e-mailing? What if you want extra logging for each e-mail, or want to implement a retry capability for failures or want to queue up e-mails to send in a batch? If you consistently use the same Gateway pattern interface for access to sending e-mails, you can add more robust infrastructure later without changing the classes that depend on IEmailGateway. Small Tests before Big Tests You want fast and accurate feedback loops on your code to flush out problems quickly. Any automated test should tell you that there Mocking Best Practices Fake objects come in many different flavors. Most of the examples in this column use stubs—simple objects that provide pre-canned answers and return values. Another type of fake is a “mock” object that is used to record or validate the interaction between classes. mocks are one of the most valuable—but confusing and misused—concepts in automated testing. Here are some best practices for getting the most out of mocks in your tests: • Do not mock or fake out calls to fine-grained or chatty interfaces like ADO.NeT that require a lot of calls. The effort involved far outstrips the reward, and those tests are generally unreadable. Only mock coarse-grained interfaces like my iemailGateway example. • Do not mock any interface or class that you do not completely understand. Be especially cautious about mocking interfaces from outside your codebase. it’s often better to write your own adapter class or gateway around external APis that expresses the functionality of that external APi in terms of your own architecture. • If you find yourself repeating the same mocking setup across multiple tests, you may want to change your design to separate the code that forces the repetitive mocking setup. • Do use mock objects as placeholders for classes that don’t yet exist, especially as a way to help determine what the public interface should be. mock objects (or stubs) allow you to investigate the shape and signature of an APi without having to build the real implementation first. For more about mocks and test doubles, see mark Seemann’s MSDN Magazine article “Unit Testing: exploring the Continuum of Test Doubles” (msdn.microsoft.com/magazine/cc163358). is a problem when something doesn’t work as expected, but a small, focused test can tell you exactly where something is wrong. When a big end-to-end test fails, you have a lot of different factors to consider, which often makes debugging harder. You still need the big end-to-end test, but my strong advice is to structure your application in such a way that you can write and test granular units of code first to flush out problems quickly before you attempt to execute end-to-end tests. In the WorkflowService example, before attempting to run the actual WorkflowService from end to end, I would do the following tests: 1. Write the WorkflowState object and test all of its business logic with various permutations of state. 2. Write a couple of tests to prove that I can correctly save and load a WorkflowState object from the database. 3. Write some interaction tests against the WorkflowService to make sure that it is correctly coordinating the IEmailGateway, IRepository, and WorkflowState objects. 4. Inside the concrete EmailGateway class, I would write unit tests to verify that it is forming the correct e-mail contents for a given WorkflowState and User object independent of sending the e-mail. Only once I am reasonably confident that every one of the pieces of WorkflowService function independently will I try to execute a full test of WorkflowService that uses the real database and sends e-mails. Smaller tests are cheaper to create, easier to understand, faster to run, and much simpler to debug. It sounds like more work to write a bunch of unit tests than a single integrated test, but I’ve frequently found it more efficient to test small units of code before attempting to integrate those units in a bigger test. The Big Picture Resources for Increasing App Testability Tools for Unit Testing with Mocks msdn.microsoft.com/magazine/cc546581 and msdn.microsoft.com/magazine/cc135981 Tame Your Software Dependencies for More Flexible Apps msdn.microsoft.com/magazine/cc337885 A Unit Testing Walkthrough with Visual Studio Team Test msdn.microsoft.com/library/ms379625.aspx I would say that my focus on testability over the past five years has had more impact on how I approach software design than anything else. Granted, there are times when I have to go out of my way in a design for no other purpose than to make the code testable. In the end, though, I think that testability goes hand in hand with the classical definition of a good design. Carefully considering the question, how can I test this in isolation? is yet another tool that will help you arrive at the classic design qualities of cohesion, coupling, and separation of concerns in your codebase.  Jeremy miller, a Microsoft MVP for C#, is also the author of the open-source StructureMap (structuremap.sourceforge.net) tool for Dependency Injection with .NET and the forthcoming StoryTeller (storyteller.tigris.org) tool for supercharged FIT testing in .NET. Visit his blog, “The Shade Tree Developer,” at codebetter.com/ blogs/jeremy.miller, part of the CodeBetter site. 42 msdn magazine Patterns in Practice http://msdn.microsoft.com/magazine/cc163358 http://msdn.microsoft.com/magazine/cc546581 http://msdn.microsoft.com/magazine/cc135981 http://msdn.microsoft.com/magazine/cc337885 http://structuremap.sourceforge.net http://storyteller.tigris.org http://www.codebetter.com/blogs/jeremy.miller http://msdn.microsoft.com/library/ms379625.aspx http://www.codebetter.com/blogs/jeremy.miller

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.