A central benefit of doing test-first development is getting a suite of behavioral tests to regress code and support refactoring efforts. But when doing test-first development in practice, many developers write too many tests and implementation-dependent tests that break during refactoring. They spend more time rewriting tests than refactoring code. The very practice that was supposed to allow them to safely make last-minute changes actually becomes an impediment to changing code. This is not a fault of TDD but rather how it has been applied. When doing TDD correctly, developers write green tests that assert against behaviors, are unique, and fail for only a single reason. Teams understanding this can then create a suite of unit tests that act as a safety net for refactoring code in the future. They may still need some red tests that validate specific implementation details as part of a Quality Assurance effort, but most test coverage will come from green tests that support refactoring. In this session, we’ll explore how to write green tests that are implementation-independent unit tests when doing TDD and how to use them to safely refactor code. Understanding how to leverage green tests that support refactoring code is key to enabling emergent design and supporting last-minute changes to code.
Do you believe you and your team could release new features to production 2 times a day with no bugs discovered in production over a year and a half? In this talk I will tell you my team and I formed the important habits that took us from hundreds of…
