“Make it public!” And other things that annoy developers about testability

Everyone agrees testing is good for quality. But to change the code just so you can test it? That would break up the developer’s perfect design! Just to make the tester’s life easier!

And if they expose inner data to the test, another not-so-smart developer will eventually call it and will blow up the world! Code doesn’t become testable by itself, we have to make it like that. And that conflicts with developer ideas of good design and how code should look.

In this session I’m going to discuss the false beliefs about testability, and how testers can discuss them with developers. Then I’m going to break them down into dust with proper testable design principles. I’ll show examples, and explore testability scenarios.

In the grand scheme of things, if developers want their code to work, it should be testable. Making those changes are not even a sacrifice for testability – they are good for everyone.

Key takeaways

  • Testable design impacts the ability to test the application properly.
  •  Testers need to understand code, so they can discuss testability with developers.
  • Identifying several patterns and pointing to them can improve testability immensely.
Track B