Test-Driven Development and Testing Early

Test-driven development (TDD) is a discipline of design and programming where every line of code is written in response to a test that the programmer writes just before coding. The idea of becoming the consumer of the code which you want to implement is very powerful and maintains a realistic expectation of how the code should be used and designed.

In TDD, the developer works in many small increments. The development of each small increment takes between a few minutes and a few hours. Typically, many such increments make up a user story. The developer check in the tests and code when the user story works. The developer works in the following cycle:

1. Write an automated test that is expected to pass when the increment is written.

2. Verify that the new test fails to help make sure that the test works.

3. Write code that will make the test pass.

4. Run the test to verify that it succeeds.

5. Also run all other tests in the same area to make sure that no bugs have been introduced.

6. Refactor the code, if necessary, to improve its structure without adding behavior. Rerun the tests to make sure that the code still works.

7. Repeat all these steps until a complete user story is implemented. As the preceding increments are integrated into a complete story, add tests that verify the full story.

8. Check in the implementation code and unit tests.

If you are interested in the benefits of test-early methods, you can start by creating manual (or manual acceptance) tests. These manual tests can be automated by creating a coded UI test. (For more information, see How to: Generate a Coded UI Test by Recording the Application Under Development.) Integration tests that use the unit test framework in Visual Studio ALM can also be created to verify functionality that is being implemented. The groups of test cases that are created early in the iteration are run early in the iteration to try to both verify functionality and find bugs. These test suites and test cases can be continuously run as regression tests throughout the life of the project. By continuing to run these tests, you help ensure that the bugs that were found and the functionality that was verified early in the iteration are not affected by change later in the project.

Use unit tests for continuous integration

---

The unit tests that are created while using the test-early practice should be organized inside the test suite for the current sprint and user story. These unit tests can be promoted to the project-wide test plan and run periodically by the team and inside the continuous integration cycle. Unit tests can also serve as a foundation for integration, load, and performance testing.

Unit tests that are created at the start can be used as part of continuous integration. For more information about how to run tests during a build, see TestToolsTask Task.   

Use virtualization to manage test configurations

---

To run unit tests, you can create a set of environments that are managed Hyper-V images in Microsoft Test Manager. For more information about how to run automated tests from a test plan by using Microsoft Test Manager, see How to: Run Automated Tests In a Lab Environment Using Microsoft Test Manager.