David Bernstein

Consultant, Author at To Be Agile


Unit Tests as Specifications
Thursday 15:25 - 16:10
Extreme Programming
Scrum, Development
Test-Driven Development
Software Quality
Emergent Design
Unit Testing

Your rating:

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


David Scott Bernstein is the author of the book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. It’s an insider’s view of the software industry drawn from his decades of hands-on experience as a software developer, trainer, and consultant to some of the biggest players in the business. With its emphasis on technical excellence, the primary audience for Beyond Legacy Code is software development managers and their teams. David’s continuing passion for software design and construction has led him to train more than 8,000 developers since 1989 at hundreds of companies around the world including Amazon, Yahoo, and Microsoft—where his book’s advice has been successfully applied. His consulting firm, To Be Agile (http://ToBeAgile.com), helps developers adopt Extreme Programming practices such as test-first development, pair programming, and refactoring.