The recommended cycle for a development task is therefore:
- Check code out of source control.
- Run the existing tests to make sure they pass. If you change the code and then find there are tests failing, you could spend a long time wondering what you did wrong.
- Delete any existing unit tests for requirements that are no longer valid. For example, suppose Mort’s requirement changes so that negative inputs just return a result of zero. He deletes the test ThrowsOnNegativeArgument, but keeps the BasicRooterTest.
a. Red: Write a new unit test and make sure it fails.
Write a new unit test:
– To test the new feature that you’re about to implement.
– To extend the range of data that you use to test. For example, test a range of
numbers rather than just one.
– To exercise code that has not previously been exercised. See the section on code
Run the test and make sure that it fails. This is a good practice that avoids the mistake of forgetting to put an assertion at the end of the test method. If it definitely fails, then you know you’ve actually achieved something when you eventually get it to pass.
b. Green: Update your application to make the tests pass. Make sure that all the tests pass—not just the new ones.
c. Refactor: Review the application code to make it easy to read and update.
Review the code to make sure that it’s easy to read and update, and performs well.
Then run the tests again.
d. Perform a code coverage check.
} until most of the code is covered by tests, and all the requirements are tested, and all the tests
It is important to know how much of your code is exercised by the unit tests. Code coverage tools give you a measure of what percentage of your code has been covered by a unit test run and can highlight in red any statements that have not been covered. Low coverage means that some of the logic of the code has not been tested. High coverage does not necessarily imply that all combinations of input data will be correctly processed by your code; but it nevertheless indicates that the likelihood of correct processing is good. Aim for about 80%.
To see code coverage results, go to the Unit Test menu and choose Analyze Code Coverage. After you run tests, you’ll see a table that shows the percentage of the code that has been covered, with a breakdown of the coverage in each assembly and method.
Choose the Coverage coloring button to see the most useful feature, which shows you which bits of the code you have not exercised. Consider writing more tests that will use those parts.
The best way to keep the server builds clean and green is to avoid checking bad code into source control. Set check-in policies to remind you and your team colleagues to perform certain tasks before checking in. For example, the testing policy requires that a given set of unit tests have passed. In addition to the built-in policies, you can define your own and download policies from the web. For more information, see the MSDN topic Enhancing Code Quality with Team Project
Users can override policies when they check in code; however, they have to write a note explaining why, and the event shows up in a report. To set a check-in policy, on the Team menu in Visual Studio choose Team Project Settings, select
Source Control. Click on the Check-in Policy tab.