MSDN Magazine - March 2008 - (Page 56)

cleanup by grouping the tests into a batch and then running the scripts before and after the batch, the execution time is still a lot longer than if you could have run the tests in-memory. Additionally, there is an even subtler problem here. Supposing that you wanted to add auditing support for the InvoiceRepository, you would be forced to create an AuditingInvoiceRepository or modify InvoiceRepository itself. Because of the coupling between InvoiceService and its child components, you don’t have many options with regard to introducing new functionality into the system. Dependency Inversion You can decouple your higher-level component, InvoiceService, from its lower-level dependencies by interacting with your dependencies via interfaces rather than their concrete classes: public class InvoiceService : IInvoiceService { private readonly IAuthorizationService authService; private readonly IInvoiceValidator invoiceValidator; private readonly IInvoiceRepository invoiceRepository; } This simple change to using interfaces (or an abstract base class) means that you can substitute an alternate implementation for any of the dependencies. Rather than creating an InvoiceRepository, you can create an AuditingInvoiceRepository (assuming that Au- Is Faking Dependencies Wise? You might be wondering whether or not it’s dangerous to “fake” your dependencies. Won’t you get false successes? Well, the reality is that you should already have tests that verify the proper functioning of your dependencies, like the real InvoiceRepository. These tests should talk to the actual database and verify that InvoiceRepository is behaving correctly. If you know that InvoiceRepository.Save works, why do you need to test it again with every single test that depends on InvoiceRepository? You’ll just slow down your higher-level tests by connecting to the database, and if there is a problem with InvoiceRepository, not only will your InvoiceRepository tests fail but so will your InvoiceService tests and any other components that depend on InvoiceRepository. If an InvoiceService test failed, but InvoiceRepository did not, it means that you missed a test on InvoiceRepository. This type of defect is better caught by integration tests, which test the component with its concrete dependencies. These run more slowly but are run less frequently than unit tests with faked/ mocked dependencies. Now assuming that InvoiceRepository works because its unit tests pass, you have two choices. You can create and maintain complex scripts to ensure that the data in the database is correct so that InvoiceRepository returns the expected data for each InvoiceService test. Or, you can create a fake or mock implementation of InvoiceRepository that returns the expected data. This second option is much easier and works well in practice. 56 msdnmagazine Dependency Injection ditingInvoiceRepository implements IInvoiceRepository). This also means that you can substitute fakes or mocks during testing. This design technique is known as programming to contract. The principle I’m applying in decoupling my high-level and lower-level components is called the dependency inversion principle. As Robert C. Martin says in his article on the topic (objectmentor.com/ resources/articles/dip.pdf), “High-level modules should not depend on low-level modules. Both should depend on abstractions.” In this case, both InvoiceService and InvoiceRepository now depend on the abstraction provided by IInvoiceRepository. However, I haven’t completely solved the problem; I merely shifted it. Although the concrete implementations only depend on an interface, the question remains how the concrete classes “find” each other. InvoiceService still needs concrete implementations of its dependencies. You could simply instantiate those dependencies in InvoiceService’s constructor, but you wouldn’t be much better off than before. If you wanted to use an AuditingInvoiceRepository, you would still have to modify InvoiceService to instantiate an AuditingInvoiceRepository. Additionally, you would need to modify every class that’s dependent on IInvoiceRepository to instantiate an AuditingInvoiceRepository instead. There is no easy way to globally swap AuditingInvoiceRepository for InvoiceRepository. One solution is to use a factory for creating IInvoiceRepository instances. This provides a central place to switch to AuditingInvoiceRepository by simply changing the factory method. Another name for this technique is service location, and the factory class responsible for managing instances is called a service locator: public InvoiceService() { this.authorizationService = ServiceLocator.Find (); this.invoiceValidator = ServiceLocator.Find (); this.invoiceRepository = ServiceLocator.Find (); } The functionality within the ServiceLocator could be based on data read from a configuration file or database, or it could be directly wired up with code. In either case, you now have centralized object creation for your dependencies. Unit testing of isolated components can be accomplished by configuring the service locator with fake or mock objects rather than the real implementations. So for example, during testing, ServiceLocator.Find could return a FakeInvoiceRepository, which assigned a known primary key to the invoice when it was saved but did not actually save the invoice to the database. You can eliminate your complex setup and teardown of the database and return known data from your fake dependencies (see the sidebar, “Is Faking Dependencies Wise?”). Service location has a few disadvantages, however. First, dependencies are hidden in the higher-level class. You cannot tell that InvoiceService depends on AuthorizationService, InvoiceValidator, or InvoiceRepository from its public signature—only by examining its code. If you need to supply different concrete types for the same interface, you must resort to overloaded Find methods. This requires you to make decisions about whether an alternate type is required when you’re implementing the factory class. For example, you can’t http://objectmentor.com/resources/articles/dip.pdf http://objectmentor.com/resources/articles/dip.pdf

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

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 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.