"Make it public!" and other things that annoy developers about testability

Everyone agrees testing is good for the 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, Gil will be going to discuss the false beliefs about testability, and how testers can discuss them with developers. Then he's going to break them down into dust with proper testable design principles. Speaker will 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 is not even a sacrifice for testability — they are good for everyone.