Test Driven Development(TDD) was the topic of chapter 5. TDD was explained as a continuous cycle of writing a test for code designed to fail at first, then writing just enough code to make it pass. These cycles repeat over and over until the final product is achieved. The purpose of this development method is to ensure we are writing code that can easily be maintained. You won’t have to worry about introducing something in your code which breaks it horribly and you can’t pinpoint the reason for it. If you write code and all of your tests fail, you know exactly where the bug was created and this simplifies the debugging process because you won’t have to search through thousands of lines of code to fix your problem.
TDD is a different process than what you do when you are first programming. At first you build an entire project and test after to make sure your program outputs exactly what you want. The fault with this method is you design tests around what you expect to happen, and you don’t take into consideration all of the possible bugs that an atypical user would find in your code. Coding this way also hinders the refactoring process because classes are tightly coupled and introducing a small bug in your program is nearly impossible to find.
From now on I will attempt this form of developing. It will be different at first and I possibly won’t be AS productive at first, but once I get the hang of it I will be sure that my code is both clean and maintainable.