ASP. net mvc 4-Test-driven ASP. NET MVC

Document directory

• Test-driven ASP. NET MVC

Test-driven ASP. NET MVC

Keith Burnell

Download Sample Code

The core of Model-View-controller (MVC) mode is to divide UI functions into three components. The model represents the data and behavior of your domain. View Management Model display and interaction with users. The Controller coordinates the interaction between views and models. In this way, the UI logic that is hard to be tested is separated from the business logic, making it easy to test applications implemented in MVC mode. In this article, I will discuss how to enhance your ASP. net mvc application testability best practices and technologies, including how to build the structure of your solution, design the code architecture to handle dependency injection, and use StructureMap to implement dependency injection.

Build the structure of your solution to achieve the highest Testability

There is no better way to start our discussion than starting a new project (that is, creating a solution) for every developer. Based on my experience in developing large enterprise ASP. net mvc applications using test-driven development (TDD), I will discuss some best practices for planning your Visual Studio solution. First, we recommend that you use an empty project template when creating an ASP. net mvc project. Other templates are suitable for testing or creating proof of concept, but they usually contain a lot of disturbing content that is distracting and unnecessary in real enterprise applications.

You should use the n-layer method when creating any type of complex applications. For ASP. net mvc application development, we recommend that youFigure 1AndFigure 2Contains the following items:

• A Web project contains all UI-specific code, including views, view models, scripts, and CSS. This layer can only access Controllers, Service, Domain, and Shared projects.
• The Controllers project contains the Controller class used by ASP. net mvc. This layer communicates with services, domains, and Shared projects.
• The Service project contains the business logic of the application. This layer communicates with DataAccess, Domain, and Shared projects.
• The DataAccess project contains the code used to retrieve and operate the data of the driver application. This layer communicates with the Domain and Shared projects.
• The Domain project contains the Domain project used by the application and prohibits communication with any project.
• A Shared project contains code that can be used for multiple other layers, such as record programs, constants, and other common utility code. Only allow this project to communicate with the Domain project.

Figure 1 interaction between layers

Figure 2 solution structure example

We recommend that you place your Controller in a separate Visual Studio project. For more information about how to easily implement this suggestion, see the blog post on bit. ly/K4mF2B. By placing your Controller in a separate project, you can further separate the logic in the controller from the UI code. The result is that your Web project only contains the real UI-related code.

Where to place your test projectIt is important to place your test projects and name them. When you develop complex and enterprise-level applications, solutions tend to become quite large. Therefore, it is difficult to locate specific classes or parts of the Code in Solution Explorer. Adding multiple test projects to your existing code library makes navigation more complex in Solution Explorer. I strongly recommend that you physically separate the test project from the actual application code. I suggest placing all test projects in the solution-level Tests folder. Locating All your test projects and tests in a single solution folder significantly reduces interference in the default Solution Explorer view, allowing you to easily locate your test.

Next, you will detach the test type. Your solution may include multiple Test types (unit, integration, performance, UI, etc.). Therefore, it is important to isolate and group each test type. This not only facilitates locating specific test types, but also allows you to easily run all tests of a specific type. If you use one of the most popular Visual Studio efficient tool kits ReSharper (jetbrains.com/ReSharper) or CodeRush (devexpress.com/CodeRush), you will get a context menu, this menu allows you to right-click any folder, project, or class in Solution Explorer and run all tests contained in this item. To group Tests by test type, create a folder for each test type you plan to write in the Tests solution folder.

Figure 3Shows an example of a Tests solution folder, which contains multiple test-type folders.

Figure 3 Example of the Tests solution folder

Name your test projectThe naming method of the test project is as important as that of the test project. You want to easily classify the applications to be tested in each test project and the Test types included in the project. Therefore, it is best to use the following Conventions to name your Test project: [full name of the project to be tested]. Test. [Test type]. This allows you to quickly and accurately determine the layer of the project to be tested and the type of the test to be executed. You may think that it is unnecessary to place a test project in a type-specific folder and include the test Type in the name of the test project, but remember, the solution folder is only used in Solution Explorer and is not included in the namespace of the project file. Therefore, although the Controllers Unit Test project is located in the Tests \ Unit solution folder, The namespace (TestDrivingMVC. Controllers. Test. Unit) does not reflect the folder structure. It is necessary to add a test type when naming a project, to avoid naming conflicts and to determine the test type that you process in the editor.Figure 4Displays the solution resource manager with a test project.

Figure 4 test project in Solution Explorer

Introduce dependency injection for your architecture

Before you encounter dependencies in your code to be tested, unit tests on n-layer applications will not go far. These dependencies can be other layers of your application, or they can be completely external to your code (such as databases, file systems, or Web services ). When you write a unit Test, you need to properly handle this situation and use Test Double (simulate, virtual, or stub) in case of external dependencies ). For more information about Test Double, see "explore the status set of Test Double" (msdn.microsoft.com/magazine/cc163358) published in MSDN September 2007 ). However, before you can use the flexibility provided by Test Double, you must design your code to handle dependency injection.

Dependency InjectionDependency injection is the process of injecting the specific implementation required by a Class (instead of directly instantiating the class of the dependency. Classes do not know the actual implementation of any dependencies, but only the interfaces that support dependencies. The specific implementation is provided by the class or dependency injection framework.

The purpose of dependency injection is to create code with a high degree of loose coupling. With loose coupling, you can easily replace the Test Double Implementation of your dependencies when writing unit tests.

There are three main methods for dependency injection:

• Property Injection
• Constructor Injection
• Use dependency injection framework/control container reversal (referred to as DI/IoC framework since then)

Using property injection, you can publish public attributes of an object so that you can set its dependency, as shown in figureFigure 5. This method is simple and clear and does not require tools.

Figure 5 Property Injection

  
  
 
   
 // Employee Service
 
   
public class EmployeeService : IEmployeeService {
 
   
 private ILoggingService _loggingService;
 
   
 public EmployeeService() {}
 
   
 public ILoggingService LoggingService { get; set; }
 
   
 public decimal CalculateSalary(long employeeId) {
 
   
 EnsureDependenciesSatisfied();
 
   
 _loggingService.LogDebug(string.Format(
 
   
 "Calculating Salary For Employee: {0}", employeeId));
 
   
 decimal output = 0;
 
   
 /*
 
   
 * Complex logic that needs to be performed
 
   
 * in order to determine the employee's salary
 
   
 */
 
   
 return output;
 
   
 }
 
   
 private void EnsureDependenciesSatisfied() {
 
   
 if (_loggingService == null)
 
   
 throw new InvalidOperationException(
 
   
 "Logging Service dependency must be satisfied!");
 
   
 }
 
   
 }
 
   
}
 
   
// Employee Controller (Consumer of Employee Service)
 
   
public class EmployeeController : Controller {
 
   
 public ActionResult DisplaySalary(long id) {
 
   
 EmployeeService employeeService = new EmployeeService();
 
   
 employeeService.LoggingService = new LoggingService();
 
   
 decimal salary = employeeService.CalculateSalary(id);
 
   
 return View(salary);
 
   
 }
 
   
}
 
   
 
 
  

This method has three disadvantages. First, it allows users to provide dependencies. Second, it requires you to implement code protection in the object to ensure that dependencies are set before use. Finally, as the number of dependencies on your object increases, the amount of code required to instantiate the object also increases.

Using constructor injection to implement dependency injection involves providing dependency to a class through its constructor when instantiating the constructor, as shown in figureFigure 6. This method is also simple and clear, but unlike property injection, you can always set the dependency of this class.

Figure 6 constructor Injection

  
  
 
   
 // Employee Service
 
   
public class EmployeeService : IEmployeeService {
 
   
 private ILoggingService _loggingService;
 
   
 public EmployeeService(ILoggingService loggingService) {
 
   
 _loggingService = loggingService;
 
   
 }
 
   
 public decimal CalculateSalary(long employeeId) {
 
   
 _loggingService.LogDebug(string.Format(
 
   
 "Calculating Salary For Employee: {0}", employeeId));
 
   
 decimal output = 0;
 
   
 /*
 
   
 * Complex logic that needs to be performed
 
   
 * in order to determine the employee's salary
 
   
 */
 
   
 return output;
 
   
 }
 
   
}
 
   
// Consumer of Employee Service
 
   
public class EmployeeController : Controller {
 
   
 public ActionResult DisplaySalary(long employeeId) {
 
   
 EmployeeService employeeService =
 
   
 new EmployeeService(new LoggingService());
 
   
 decimal salary = employeeService.CalculateSalary(employeeId);
 
   
 return View(salary);
 
   
 }
 
   
}
 
   
 
 
  

Unfortunately, this method still requires users to provide dependencies. In addition, it is indeed only applicable to small applications. Large applications usually have too many dependencies, so they cannot be provided through object constructors.

The third method to implement dependency injection is to use the DI/IoC framework. The DI/IoC framework completely eliminates the user's responsibility for providing dependencies, and allows you to configure dependencies during design and parse dependencies at runtime. There are many DI/IoC frameworks available for. NET, including Unity (Microsoft products), StructureMap, Castle Windsor and Ninject. The basic concepts behind all different DI/IoC frameworks are the same, and the framework to choose is usually determined by personal preferences. To demonstrate the DI/IoC framework in this article, I will use StructureMap.

Use StructureMap to inject dependency to a higher level

StructureMap (structuremap.net) is a widely used dependency injection framework. You can use the Package Manager Console (Install-Package StructureMap) or NuGet Package Manager GUI (right-click the reference folder of your project and select "manage NuGet packages ") install the framework through NuGet.

Use StructureMap to configure DependenciesThe first step to implement StructureMap in ASP. net mvc is to configure your dependencies so that StructureMap knows how to parse them. You can configure the dependency in the Application_Start method of Global. asax in either of the following methods.

The first method is to manually indicate StructureMap. For specific abstract implementations, it should use specific implementations:

  
  
 
   
 ObjectFactory.Initialize(register => {
 
   
 register.For<ILoggingService>().Use<LoggingService>();
 
   
 register.For<IEmployeeService>().Use<EmployeeService>();
 
   
});
 
   
 
 
  

The disadvantage of this method is that you must manually register every dependency in your application. Therefore, for large applications, the workload may be high. In addition, because you register dependencies in Application_Start of the ASP. net mvc site, your Web layer must directly know each other layer of the application bound with dependencies.

You can also use StructureMap to automatically register and scan your programs and bind dependencies. In this method, StructureMap scans your assembly and finds the specific implementation of the association when it encounters an interface (based on a concept, that is, according to the Convention, the method named IFoo will be mapped to the specific implement Foo ):

  
  
 
   
 ObjectFactory.Initialize(registry => registry.Scan(x => {
 
   
 x.AssembliesFromApplicationBaseDirectory();
 
   
 x.WithDefaultConventions();
 
   
}));
 
   
 
 
  

StructureMap dependency SolutionAfter configuring your dependencies, you must be able to access these Dependencies from your code library. This is achieved by creating a dependency-based solution and positioning it in a Shared project (because it will be accessed by all application layers with dependency ):

  
  
 
   
 public static class Resolver {
 
   
 public static T GetConcreteInstanceOf<T>() {
 
   
 return ObjectFactory.GetInstance<T>();
 
   
 }
 
   
}
 
   
 
 
  

Resolver class (I like to call it this way, because Microsoft and ASP. net mvc 3 introduce the DependencyResolver class together and I will discuss it later) is a simple static class that contains a function. This function accepts the generic parameter T, which indicates that it is used to find the specific implemented interface and returns T, which is the actual implementation of the incoming interface.

Before I jump to how to use the new Resolver class in your code, I would like to explain why I have compiled a self-developed dependency solution program instead of creating an implementation with ASP.. net mvc 3 introduces the IDependencyResolver interface class. Including IDependencyResolver is a great supplement to ASP. net mvc and has made great progress in promoting correct software behavior. Unfortunately, it resides in System. web. mvc dll, and I do not want to reference libraries specific to Web technologies in non-Web layers of the application architecture.

Parse dependencies in the codeAfter completing all the difficult work, it is easy to parse the dependencies in the code. All you need to do is to call the static GetConcreteInstanceOf function of the Resolver class and pass it to you to find the specific implemented interface for it, as shown inFigure 7.

Figure 7 parse the dependency in the code

  
  
 
   
 public class EmployeeService : IEmployeeService {
 
   
 private ILoggingService _loggingService;
 
   
 public EmployeeService() {
 
   
 _loggingService = 
 
   
 Resolver.GetConcreteInstanceOf<ILoggingService>();
 
   
 }
 
   
 public decimal CalculateSalary(long employeeId) {
 
   
 _loggingService.LogDebug(string.Format(
 
   
 "Calculating Salary For Employee: {0}", employeeId));
 
   
 decimal output = 0;
 
   
 /*
 
   
 * Complex logic that needs to be performed
 
   
 * in order to determine the employee's salary
 
   
 */
 
   
 return output;
 
   
 }
 
   
}
 
   
 
 
  

Use StructureMap to inject Test Double into unit TestThe code structure has been completed. Therefore, you can inject dependencies without user intervention. Let's go back to the initial task of correctly handling dependencies in unit testing. The specific situation is as follows:

• This task is written using TDD logic to generate the salary value to be returned from the CalculateSalary method of EmployeeService. (You willFigure 7EmployeeService and CalculateSalary functions are found in .)
• There is a requirement that all calls to the CalculateSalary function must be recorded.
• The interface for log service will be defined, but the implementation is incomplete. Currently, an exception is thrown when the logging service is called.
• The task needs to be completed before the Log service starts as planned.

You may have encountered this type before. But now you have the correct architecture and can get rid of the dependency constraints by implementing Test Double. I like to create a Test Double shared among all my Test projects in a project. For exampleFigure 8As shown in, I have created a Shared project in the Tests solution folder. In this project, I added a Fakes folder, because in order to complete my test, I need the virtual Implementation of ILoggingService.

Figure 8 shared test code and virtual Projects

It is easy to create virtual settings for log service. First, I created a class named LoggingServiceFake In the Fakes folder. LoggingServiceFake must meet the expectations of EmployeeService, which means it must implement ILoggingService and its methods. As defined, virtual hosting is a substitute, containing code that satisfies the interface. In general, this means that it has an empty Implementation of the void method, and the function implementation contains the return statement that returns the hard-coded value, as shown below:

  
  
 
   
 public class LoggingServiceFake : ILoggingService {
 
   
 public void LogError(string message, Exception ex) {}
 
   
 public void LogDebug(string message) {}
 
   
 public bool IsOnline() {
 
   
 return true;
 
   
 }
 
   
}
 
   
 
 
  

Now virtual settings have been implemented. I can write and test them. At the beginning, I will create a Test class in the TestDrivingMVC. Service. Test. Unit Test project. According to the naming conventions described above, I name it EmployeeServiceTest, as shown inFigure 9.

Figure 9 EmployeeServiceTest test class

  
  
 
   
 [TestClass]
 
   
public class EmployeeServiceTest {
 
   
 private ILoggingService _loggingServiceFake;
 
   
 private IEmployeeService _employeeService;
 
   
 [TestInitialize]
 
   
 public void TestSetup() {
 
   
 _loggingServiceFake = new LoggingServiceFake();
 
   
 ObjectFactory.Initialize(x => 
 
   
 x.For<ILoggingService>().Use(_loggingServiceFake));
 
   
 _employeeService = new EmployeeService();
 
   
 }
 
   
 [TestMethod]
 
   
 public void CalculateSalary_ShouldReturn_Decimal() {
 
   
 // Arrange
 
   
 long employeeId = 12345;
 
   
 // Act
 
   
 var result = 
 
   
 _employeeService.CalculateSalary(employeeId);
 
   
 // Assert
 
   
 result.ShouldBeType<decimal>();
 
   
 }
 
   
}
 
   
 
 
  

In most cases, the test code is very simple. Note the following code lines:

  
  
 
   
 ObjectFactory.Initialize(x =>
 
   
 x.For<ILoggingService>().Use(
 
   
 _loggingService));
 
   
 
 
  

This is the code that instructs StructureMap to use LoggingServiceFake when the Resolver class we created previously attempts to parse ILoggingService. I place this code in a method marked with TestInitialize, which indicates that the unit test framework runs this method before each test in the test class.

By using powerful DI/IoC and StructureMap tools, I can completely get rid of the constraints of the logging service. This enables me to complete coding and unit testing without being affected by the Log service status, and write real unit test code that does not depend on any dependencies.

Use StructureMap as the default controller FactoryASP. net mvc provides an extension that allows you to add custom implementations that instantiate controllers in your applications. By creating a class inherited from DefaultControllerFactory (seeFigure 10), You can control how to create a controller.

Figure 10 custom controller Factory

  
  
 
   
 public class ControllerFactory : DefaultControllerFactory {
 
   
 private const string ControllerNotFound = 
 
   
 "The controller for path '{0}' could not be found or it does not implement IController.";
 
   
 private const string NotAController = "Type requested is not a controller: {0}";
 
   
 private const string UnableToResolveController = 
 
   
 "Unable to resolve controller: {0}";
 
   
 public ControllerFactory() {
 
   
 Container = ObjectFactory.Container;
 
   
 }
 
   
 public IContainer Container { get; set; }
 
   
 protected override IController GetControllerInstance(
 
   
 RequestContext context, Type controllerType) {
 
   
 IController controller;
 
   
 if (controllerType == null)
 
   
 throw new HttpException(404, String.Format(ControllerNotFound,
 
   
 context.HttpContext.Request.Path));
 
   
 if (!typeof (IController).IsAssignableFrom(controllerType))
 
   
 throw new ArgumentException(string.Format(NotAController,
 
   
 controllerType.Name), "controllerType");
 
   
 try {
 
   
 controller = Container.GetInstance(controllerType) 
 
   
 as IController;
 
   
 }
 
   
 catch (Exception ex) {
 
   
 throw new InvalidOperationException(
 
   
 String.Format(UnableToResolveController, 
 
   
 controllerType.Name), ex);
 
   
 }
 
   
 return controller;
 
   
 }
 
   
}
 
   
 
 
  

In this new controller factory, I have a public StructureMap container attribute, which obtains the Set Based on StructureMap ObjectFactory (inFigure 10In Global. asax ).

Next, I have an alternative to the GetControllerInstance method that executes some type of check, and then use the StructureMap container to parse the current controller based on the provided controller type parameters. Because I used the StructureMap Automatic Registration and scanning feature when I first configured StructureMap, no other operations are required.

The benefit of creating a custom controller factory is that your controller is no longer limited to non-parametric constructors. In this case, you may have the following question: "How do I provide parameters to the Controller constructor ?". With the scalability of DefaultControllerFactory and StructureMap, you do not have to provide parameters. When you declare a parameterized constructor for the controller, the dependency is automatically parsed when the controller is resolved in the new controller factory.

For exampleFigure 11As shown in, I have added an IEmployeeService parameter to the HomeController constructor. When the controller is resolved in the new controller factory, all parameters required by the Controller's constructor are automatically parsed. This means that you do not need to manually add code to parse the Controller dependency-but you can still use the virtual settings as described above.

Figure 11 Resolution Controller

  
  
 
   
 public class HomeController : Controller {
 
   
 private readonly IEmployeeService _employeeService;
 
   
 public HomeController(IEmployeeService employeeService) {
 
   
 _employeeService = employeeService;
 
   
 }
 
   
 public ActionResult Index() {
 
   
 return View();
 
   
 }
 
   
 public ActionResult DisplaySalary(long id) {
 
   
 decimal salary = _employeeService.CalculateSalary(id);
 
   
 return View(salary);
 
   
 }
 
   
}
 
   
 
 
  

By using these practices and technologies in your ASP. net mvc application, the entire TDD process will be easier and more concise.

Keith Burnell Is a senior software engineer at Skyline Technologies. He has been engaged in software development for more than 10 years and specializes in large-scale ASP. NET and ASP. net mvc website development. Burnell is actively involved in the developer community. You can visit dotnetdevdude.com to view his blog, or visit twitter.com/keburnell to view his microblog.

Original article:Http://msdn.microsoft.com/zh-cn/magazine/jj190803.aspx

We sincerely thank the following technical experts for reviewing this article: John Ptacek and Clark NLP