Introducing XP—XP Practice 7.1: Test-Driven Development and Unit Tests

Microsoft .NET Framework, ASP.NET, Visual C# (CSharp, C Sharp, C-Sharp) Developer Training, Visual Studio

Test-Driven Development and Unit Tests

Test-driven development (TDD) promotes the writing of tests prior to writing the code that is being tested. This allows you to focus on your interface and what you expect from your code prior to focusing on its particular implementation.

The testing components for implement a test-driven development plan are known as unit tests. Unit tests are small pieces of code that are written to exercise autonomous “units” of your implemented classes. When developing these tests, you usually focus on the public interfaces of your classes. A common test-driven development sequence looks something like the following:

1. Create a unit test that will exercise the class that you intend to create.

2. Compile your unit test. It will fail to compile, because the code you’re trying to test doesn’t exist.

3. Write just enough functionality to allow the unit test to compile.

4. Run your test. It will fail, because you haven’t actually implemented the class.

5. Write your class implementation.

6. Run your test again. You should now have a test that passes. (If it doesn’t, back up one step and try again.)

Test-driven development gives developers the confidence to make changes to the system, because they know that the tests will tell them if they have broken anything and where in the application the break occurred. This is one of the most effective feedback mechanisms that the development team can have for ensuring stability and high quality.

Another advantage to test-driven development is that it assists in keeping the code simple. When developers take a code-first approach to development, they have a tendency to design as they code, without having a clear picture as to what they want to achieve. They basically let the creative process lead them to a design while they are coding. This often does not result in the most straightforward solutions. In fact, in many cases, it results in an overly complicated design. Test-driven development forces developers to think about the outcome of what they are developing, and then simply code until the test passes, which leads to a simpler design. This is called development by intention.