Loading…
Agile2018 has ended
Tuesday, August 7 • 09:00 - 10:15
Unit Tests as Specifications (David Bernstein)

Sign up or log in to save this to your schedule and see who's attending!

Limited Capacity seats available


Abstract:
Test-driven development (TDD) is an essential developer 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 "test until bored," but we all have different thresholds for boredom so developers who follow this advice can end up writing too many tests and tests that break during refactoring. In this session, we'll discover how to determine 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 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.

Learning Outcomes:
  • Identify the minimal number of tests required to specify a behavior
  • Write unit tests that validate behavior, not implementation
  • Instrument tests so they clearly read like specifications
  • Build test suites that act as a safety net for refactoring
  • Avoid many common pitfalls when doing TDD
  • Use unit tests to specify testable behaviors

Attachments:

Speakers
avatar for David Bernstein

David Bernstein

Consultant, To Be Agile
David Scott Bernstein is the author of the new 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... Read More →


Tuesday August 7, 2018 09:00 - 10:15
Marina F