Topics:
Agile
Extreme Programming
Scrum, Development
Test-Driven Development
Software Quality
Emergent Design
Unit Testing
Instrumentation
Test-driven development (TDD) is a valuable practice for rapidly building quality software. But the unit tests we write with TDD can do more than just verify our code. They can also serve as clear specifications for creating testable behaviors that support refactoring. Many developers find that their unit tests break and require effort to maintain when they’re refactoring code. The conventional wisdom for doing TDD is to “test until bored,” but we all have different thresholds for boredom, so developers who follow this advice can end up writing tests that break during refactoring. In this session, we’ll discover how to define the right kind and number of unit tests needed to specify any behavior. This helps ensure that we’re creating tests that clearly document the behavior of the system and support us in refactoring our code later.
Writing good unit tests is a critical skill that developers need to master in order to get the most benefit from doing TDD. Tests must be unique, written at the right level of abstraction, and implementation-independent in order to be the most valuable. When we understand how to use tests to articulate the behaviors we want to create, we can recognize the correct number and kind of tests needed to describe the behavior we want to build, putting every member of a team on the same page and building the right kind and number of tests that drive the creation of any behavior in the system. When we do this our tests become a form of living specifications.
In this session, we’ll cover effective techniques for doing TDD that support building useful tests and quality code. You’ll learn how to instrument unit tests, so they also act as specifications that make a test’s intention clear. You’ll also learn how to approach TDD in a way that yields the right number and kind of tests that allow you to refactor code later without breaking tests. Working through a few code examples, we’ll see how many assertions are required to specify a linear range, exceptions, and other boundary conditions. We’ll look at how to write tests that don’t need to be changed when the code is refactored while still keeping test coverage high. If you’ve struggled to apply TDD on a project, or are just not sure how to start, then this session is for you.
Check the slides
