Introduction

Many people think that Test-Driven Development (TDD) is all about testing software. In fact, test-driven development s main goal is not testing software, but aiding the programmer and customer during the development process with unambiguous requirements. The requirements are expressed in the form of tests, which are a support mechanism (scaffolding, you might say) that stands firmly under the participants as they undertake the hazards of software development. However, that is not the only purpose of testing. As you will see, the tests, once written, are valuable resources in their own right.

What Are the Benefits of Using Tests?

It is important during development that problems are discovered early and corrected when they are found. Often, the biggest problems occur when there is a misunderstanding of a requirement between the consumers of the software (customers) and the producers (programmers). These types of problems could be avoided if there were a way to specify these requirements unambiguously before development begins. Enter tests. The tests specify requirements in a way that does not require human interpretation to indicate success or failure. If there is a sufficient number of tests and they are present prior to development, simply running the tests and indicating success or failure helps solve the old problem of software development, Are We Done? The answer is no longer an interpretation; the code either passes all the tests or it does not. After it passes , it s done.

Solving this problem alone may be justification enough, but is there more? The tests that are written during development can be run and enhanced by Quality Assurance (QA) with tests of their own. Due to the code being written with testing as a primary motivation, the resulting code should be easier to test. Having a base of existing tests and code that is easier to test should allow QA to shift from a reactive mode into a more proactive mode.

The tests themselves are useful not only in the initial development of the software; if they are maintained along with the production code, they can be used in the ongoing development of the software. For example, if a problem is discovered in the production code, the first step should be to write a test to clearly identify the problem and then, after you have a failing test, correct the problem. This new test specifies a scenario that was not identified during the prior development. If you do this consistently, the tests will evolve into how the program is used in real life, which increases their value exponentially. When adding new features, you could run this suite of tests to ensure that the new code does not break any of the existing tests. If the test coverage is sufficient; running the tests and getting a successful result should reduce your fear of moving forward. Fear of breaking existing functionality can cause you to become overly cautious, which slows you down. Think of the tests as a way of covering your back.

An Example

Let s look at an example to demonstrate how tests can describe a requirement more clearly than words can. Consider the following description of a Stack. A Stack is a data structure in which you can access only the item at the top. With a computer, Stack just like a stack of dishes ”you add items to the top and remove them from the top ( http://www.developersdomain.com/vb/articles/stack.htm ). This is not a bad description, but it does not specify method names and it uses an analogy that might not resonate with people. In short, it leaves a great deal open to interpretation, and you would get many implementations that could satisfy this definition.

Now look at a test that specifies the same thing:

 [Test]    public void PushPop()    {       string name = "Name";       Stack stack = new Stack();       stack.Push(name);       Assert.AreEqual(name, stack.Pop());    } 

This code specifies the names of methods , how they are called, and what they should return. It also specifies a sequence that yields a successful result. Finally, the test is executable, meaning that you can run it on the production code, and it will inform you if your implementation passes the test. The only thing that is open to interpretation is how you should implement the Stack , which is exactly what you want if you are a programmer. If your job was to implement a Stack , would you rather have your specification described as a series of tests or as a written specification?

Organization

This book is organized into two sections, followed by three appendixes.

• Part I: Test-Driven Development Overview This section describes the concepts of test-driven development. It begins with Kent Beck s rules, provides some additional detail about how to use and apply these rules, defines terminology that we use throughout the book, and defines a process for doing test-driven development. In addition to the definitions, we also demonstrate how to apply them by example. The focus in these early chapters is on completeness and following the principles and practices as written.

• Part II: The Test-Driven Development Example This section demonstrates how to do Test-Driven Development on a realistic n - tier application. The application, a media library, is specified in Chapter 4, The Media Library Example. As well as implementing the expected functionality, we also investigate important real-world application areas that are typically avoided in sample applications. For example, we demonstrate the use of TDD with concepts such as exception handling and database connectivity. By the end of the sample, you ll have a good grounding in the techniques needed to use TDD in your own enterprise projects.

• Appendix A: NUnit Primer This appendix contains an introduction to the tool, NUnit.

• Appendix B: Transactions in ADO.NET This appendix provides an overview of transaction support in the .NET Framework.

• Appendix C: Bibliography The bibliography lists the works by other people that we have used ourselves and referred readers to throughout this book.