Abstract: We all know what TDD is but few of us practice it consistently, and still fewer have realized the benefits it promises. We need to recognize when TDD has turned from a solution to another problem. TDD is supposed to help us refactor our code safely but we often find that when we refactor our code we also have to refactor our tests, and what was supposed to add safety becomes a burden, requiring time and effort to refactor tests.
Writing good unit tests is a critical skill that developers need to master in order to get the most benefit from doing test driven development. Tests must be unique, written at the right level of abstraction, and implementation-independent in order to be most valuable. In this session, we’ll cover effective techniques for doing TDD that support building useful tests and quality code. You'll learn how to approach TDD in a way that yields the right number and kind of tests to support refactoring.
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.
Learning Outcomes: - Avoid the common pitfalls of doing TDD
- Identify the minimal number of tests required to specify a behavior
- Avoid writing implementation-dependent tests
- Build test suites that acts as a safety net for refactoring
- Use unit tests to specify testable behaviors
Attachments:
