There’s a flip side. A culture that thinks end-to-end testing is the only legitimate way to test a system and that TDD is an unnecessary expense that is neither

There’s a flip side. A culture that thinks end-to-end testing is the only legitimate way to test a system and that TDD is an unnecessary expense that is neither necessary nor sufficient for success. That culture is right, but it’s also wrong [1]. Although it is true that you can spend most of your time testing, providing little value, it’s equally true that with any software system, that by developing it, you will break it in subtle ways; ways in which you could spend weeks fixing bugs you introduced and fixed before, therefore creating little value. Unfortunately there is no substitute for critical thinking when engineering. This piece says we need to practice critical thinking with tests and that having a test that moves a mouse and clicks to confirm functionality, with suites that take 40 minutes to run, is going too far. Ball cites two examples of projects that strike a balance in testing speed and coverage. But how do we achieve this? I used “culture” in a specific way to describe working environments. Culture, not process, politics, or incentives, drives how you do testing. A culture is an environment that has preferences. A culture that will generate good tests is a culture that values technical rigor. Rigor is important for forging tests, but it’s also important for removing tests. To make these good test suites, we need to be comfortable with removing tests, but more importantly understand why a test is needed and remove it when we can’t explain it. [1] I’m not going to say there’s a “balance” to be struck, because that’s the language of people who say we should not write any tests.