Talk details

We need to write tests that run different scopes of the system in order to feel confident that our code behaves the way we want it to. Unfortunately, we'll never write enough tests to feel perfectly confident, so we need a strategy for which tests to focus on and which tests not to write.

And this is where the arguments start. They're not always constructive and they're rarely fun.

Best Practices thinking lures the typical programmer into trying to pick one testing strategy that they can always follow, and since it's possible to have microtests that pass and still have bugs, they often conclude only integrated tests can fill in the gaps of their testing. Then these tests begin to feel like the only truly reliable tests in their strategy. Then they over-rely on them and production slows down to a crawl all around them...

In this talk, I warn you about the integrated tests scam: how they act as medicine that eventually makes your sickness worse. I offer an alternative approach to gaining confidence in the correctness of your code. I describe why you need multiple strategies and how to find a helpful balance among them in your context. Every time. Without the drawbacks of Best Practices thinking.

Oh, and one more thing: if you don't like your tests, the problem probably lies in the design of your production code. The coupling that you don't like in your tests is merely a reflexion of the design risks in your production code. So many arguments and so much doubts disappears when we refactor.