Test-driven development is a core practice of Extreme Programming (XP) and the “secret sauce” for some teams, enabling them to rapidly build quality code. But for other teams it’s an impediment that keeps them from refactoring code and increases their technical debt. TDD is supposed to help us refactor code safely but we often find that when we refactor our code we also have to change our tests, and what was supposed to add safety becomes a burden, requiring time and effort to keep tests up to date.
Writing good unit tests is a critical skill that developers need to master in order to get the most benefit from test-driven development. Tests must be unique, written at the right level of abstraction, and implementation-independent in order to be 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. 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’re more readable and flexible. Instrumentation helps make a test’s intention clear and removes magic numbers from code.
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 it. 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 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.
