MSDN Magazine - March 2008 - (Page 55)

ensure that each test’s initial data is independent of other tests’ initial data, or you can run into test ordering problems where certain tests fail if run out of order. MaintainHow confident are you that your data layer will only talk ing the database in a known good state is time-consuming to SQL Server® or that you’ll always load your app settings and error prone. from an XML document named Settings.xml? The intent Additionally, if you need to change the implementation of here is not to build an infinitely extensible but hugely coma lower layer, you’re often forced to modify the upper layers Figure 1 plex and unusable generic framework. It is about reversibilas well due to implicit or explicit dependencies that those Typical ity. How easily can you change your mind with respect to layers have on the lower layer. Although you have layered Layered design decisions? Do you have an application architecture Architecture the application, you have not achieved loose coupling. that responds well to change? Let’s take a look at a concrete example—a service that acWhy am I worried about change? Because practically the only cepts invoices (see Figure 2). For InvoiceService.Submit to be able constant in this industry is change. Requirements change, tech- to accept an invoice submission, it depends on an Authorizationnologies change, developers change, and the business changes. Are Service, InvoiceValidator, and InvoiceRepository, which are creyou putting yourself in a position to respond to those changes? By ated in the class’s constructor. You cannot unit test InvoiceService creating loosely coupled designs, software can better respond to without its concrete dependencies. This means that before you run inevitable, and many times unforeseeable, changes. your unit tests, you must ensure that the database is in a state such that you will not cause any primary or unique key violations when The Inner Dependency Problem InvoiceRepository inserts the new invoice, nor must InvoiceValiLet’s examine a typical highly coupled design that you’ll find in dator report any validation failures. You must also ensure that the your average layered application architecture (see Figure 1). A simple user running the unit tests has the correct permissions so that Aulayering scheme has a UI layer that talks to a service (or business) thorizationService will permit the “Submit” operation. layer that talks to a repository (or data) layer. The dependencies beThat is a tall order. If there are problems in any of these dependent tween these layers flow the same way down. The repository layer is components, either code or data errors, the InvoiceService tests will unaware of the service layer, which is unaware of the UI layer. fail unexpectedly. Even if the test passes, the total execution time Sometimes you have a few more layers, such as a presentation will be a few hundred milliseconds between setting up the correct or workflow layer, but the pattern of layers being aware only of the data in the database, executing the tests, and cleaning up any data layer beneath them is fairly typical. Layers as coherent clusters of created by the test. Even if you amortize the cost of the setup and responsibility are a good design technique. Direct coupling of upper layers to lower layers, however, increases coupling and makes Figure 2 Invoice Service the application difficult to test. public class InvoiceService { Why am I concerned with testability? Because testability is a good private readonly AuthorizationService authoriazationService; private readonly InvoiceValidator invoiceValidator; barometer of coupling. If you can’t easily instantiate a class in a test, private readonly InvoiceRepository invoiceRepository; you have a coupling problem. For example, the service layer is inpublic InvoiceService() { timately familiar with and dependent on the repository layer. We authoriazationService = new AuthorizationService(); cannot test the service layer in isolation of the repository layer. On invoiceValidator = new InvoiceValidator(); invoiceRepository = new InvoiceRepository(); a practical level, this means that most tests access the underlying } database, file system, or network. This leads to a variety of probpublic ValidationResults Submit(Invoice invoice) { lems, including slow tests and high maintenance costs. ValidationResults results; Slow Tests If tests can execute strictly in memory, time per test CheckPermissions(invoice, InvoiceAction.Submit); results = ValidateInvoice(invoice); can be in the millisecond range. If tests access external resources, SaveInvoice(invoice); such as a database, file system, or network, time per test is often return results; } 100 milliseconds or more. Considering that a typical project with good test coverage has hundreds or thousands of tests, this can private void CheckPermissions(Invoice invoice, InvoiceAction action) { if(authoriazationService.IsActionAllowed(invoice, action) == false) { mean the difference between running your tests in a few seconds throw new SecurityException( versus minutes or hours. “Insufficient permissions to submit this invoice”); } Poor Error Isolation A failure in a data layer component often } causes tests of upper-layer components to fail, too. Rather than private ValidationResults ValidateInvoice(Invoice invoice) { having a few tests fail, which helps you quickly isolate the probreturn invoiceValidator.Validate(invoice); lem, you have hundreds of failing tests, which makes finding the } problem difficult and more time-consuming. private void SaveInvoice(Invoice invoice) { High Maintenance Costs Most tests require some initial data. invoiceRepository.Save(invoice); } If those tests touch the database, you must ensure that your da} tabase is in a known state before each test. In addition, you must Or even this one: XmlDocument settings = new XmlDocument(); settings.Load(“Settings.xml”); march2008 55

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.