When we write our code test first we are forced to make decisions about how the application will operate. We have to express the intent of our code using expectations and verifications before we ever begin implementing any actual functionality. By writing code test first we free ourselves to mold our API from the perspective of a consumer, almost ensuring that we end up with a simple API containing only what is absolutely essential. A powerful side-effect of TDD is testability. When we write code test first we end up with a set of specifications which can be used to verify the behavior of our application. When these specifications are checked (by running the suite of tests) we can verify that our application behaves appropriately. When a change is made to the behavior of our application, these specifications will indicate (by way of failing tests), that such a change has been made. The testability aspect of TDD, while quite helpful is not the main focus of TDD it is only a side-effect. While TDD forces us to create high quality code (because we must test pieces of the system in isolation) , doing TDD doesn’t guarantee we’re going to produce bug-free code! TDD needs the accompaniment of Integration Testing and Acceptance Testing in order to ensure quality. If TDD were a drawing, integration and acceptance testing would be the frame you’d place your finished masterpiece within.

1. christinaert liked this
2. kasiprasad posted this