Have you heard about this practice called Test-Driven Development? When asked this question, the most common response is “I’ve heard about it, but never used it in my day-to-day work” or “I only write tests after the production code”. While popularised by eXtreme Programming in the early 2000s, the practice of TDD is in a steep decline. So in order to prevent this loss, we have to rediscover the basics of Test-Driven Development. Although the premise of Red-Green-Refactor sounds easy enough at first, there’s a lot more to it than just writing a failing test, making the test pass and refactoring the code a bit.

For starters, we find that there are generally two different types of verification: state verification and behaviour verification. How and, most importantly, when should we apply these types of verification? Then there are also two different approaches to TDD itself. Which of these should we choose? What about test doubles? How do I find a good boundary for my unit tests? In this talk, we’re going to start from the history of Test-Driven Development all the way to why it’s important to find a good balance in TDD and how to accomplish this.