asp.net MVC contact Manager Development Tour Iteration 5

Iteration 5 Building Unit tests

This iteration

In the last iteration of the contact Manager, we refactored the program by using some design patterns, loosening the coupling between classes. We separate the controller, service and repository layers separately. Each layer interacts with the other layers based on the interface.

By refactoring, the application becomes more maintainable and modified. If one day you need to use other data storage technology, so long as the simple replacement repository layer can, do not need to touch the controller or the service layer code.

But what if we need to add new features to the contact Manager or fix bugs? The brutal truth tells us that every time we change the code, we must take the risk of new bugs.

For example, one day, your head needs you to add a new feature to the contact Manager. She asked the program to support grouping of contact information, and she asked users to customize some of these groupings such as "friends" and "co-workers" to organize their contact information.

To achieve this, you need to modify the code in all three layers of the contact manager. You need to add a series of new functions to the Controller, service, and repository layers. From the moment you start to modify the code, you have to take the risk of damaging the part of the function that might otherwise be working properly.

The last time we refactored the application and spread it across several separate layers, we could make a change to a layer without touching other code. However, when you want the code in this particular layer to be easier to maintain and modify, you should set up unit tests for your code.

You can test a unit test against a specific unit of code. These code units are much smaller than the entire layer. For example, if you test a particular method in your code to see if it achieves the desired function and performance, this is a classic unit test scenario. If you want to make a unit test of the CreateContact () method exposed by the Contactmanagerservice class.

Unit tests are more like a secure network for the entire application development process. When you want to modify the code in your application, you can perform a series of unit tests to see if your new code is damaging to the original functionality. Unit testing provides a higher safety factor for your code modification, and unit testing makes the code change scenarios in your application more resilient.

In this iteration, we add unit tests to the contact Manager. Thanks to this, in the next iteration we can add new contact group functionality without worrying about whether the changes will affect the original functionality.

Well, start here.

In a perfect world, all the code in an application is unit tested. In the perfect world, you have a perfect secure network system, you can modify the application of any one line of code and immediately through the unit test to know whether these changes will affect the original function.

Yet the world is not perfect in most cases. In practice, when we do unit testing, you need to focus on testing the business logic (for example, validation logic). In exceptional cases, you do not need to unit test the data Access logic or the view logic.

Unit tests must be quick to execute. You will easily accumulate hundreds of unit tests for your application. If it is time-consuming to run some unit tests, you should avoid implementing them. In other words, time-consuming unit tests are not useful for day-to-day coding.

Therefore, you do not need to unit test the code that actually interacts with the database. Running hundreds of unit tests against the database will be slow. You should mock your database and then write the code to interact with the mock database. (We'll discuss how to mock the database below)

Similarly, you don't have to do unit testing for view. To test the view, you have to build a Web server. Because it is relatively time-consuming to build a Web server, there is no recommended unit test for view.

If your view contains a lot of complex logic, you should consider moving these logic into the helper method. You can write unit tests for helper methods without having to build a Web server.

Although testing for data storage logic or attempted tests is not recommended, these tests may be useful when integrating or functional testing.

asp.net MVC uses the Web form to attempt the engine by default. The engine relies on a Web server, and other attempts at the engine may not be the same.