Building the Case for TDD
Before we dive into what test-driven development (TDD) is and how to use it, we’re going to need to understand why we need it. Every seasoned developer knows that bad code is easier to write than good code. Even good code seems to get worse over time. Why?
In this chapter, we will review the technical failures that make source code difficult to work with. We’ll consider the effect that bad code has on both the team and the business bottom line. By the end of the chapter, we’ll have a clear picture of the anti-patterns we need to avoid in our code.
In this chapter, we’re going to cover the following main topics:
- Writing code badly
- Recognizing bad code
- Decreasing team performance
- Diminishing business outcomes
