We all know by now how to write automated tests. But can we get better at it? For example, how can we make sure we go beyond “happy path testing” and create really strong test suites? Is code coverage a bad metric we should ignore, or can it actually help us? Should we go for unit or integration tests? Or are E2E tests much better for more complex systems? Is TDD really a must? Or can we design testable systems without it?

In this talk, I share lessons I learned over time:

  1. Testing supports development and bug finding
  2. Being systematic helps you create better test cases
  3. Bugs love boundaries
  4. Code coverage is a good tool
  5. Unit vs integration tests don’t matter; fast tests do
  6. Dividing and conquer is the way to test complex systems
  7. Testing has to be easy, otherwise no one will do it
  8. TDD or not TDD: what matters is quick feedback
  9. Making code testable is key to happiness
  10. You should trust your test suite
  11. Testing isn’t magical!

This talk is based on my recent Effective Software Testing: A Developer’s Guide, published by Manning. You can buy is with 35% discount by using the “au35ani” discount code.

Video

I thank CODAM for the beautifully recorded video!

Thanks ACM Tech Talks for the invite!

Slides

Link to the Google Docs presentation, if you want to reuse it.

(There are older versions of this presentation, maybe you have seen them? The slides might differ a bit from the version you saw, as I keep improving them as I go!)