Journey to TDD - Not Always

If you found this article and want to start at the beginning, this series starts here.

From writing copious amounts of tests, I notice I have fewer code style conversation because the tests covered it.

Working in a test heavy environment upgraded my thinking and approach. At the same time, the tests were heavy. Almost one hour for full suite. Were we testing too much?

At the same time, there’s a bigger question - is it worth testing so much at a startup?

I’ve covered Kent Beck’s 3x Rule and I understand testing can impede something larger: business’ speed to innovation. The business doesn’t even know what works so it will try things, rapidly.

If tests are the things that are slowing down the business from succeeding, there’s probably a bigger question the business needs to address than “software testing”.

My rule of thumb of when to have tests: when the business starts to have revenue from the software the team is building. That starts a chain of events where writing tests afterwards becomes difficult.

When you don’t have to write tests, does that mean this is a free pass to not test?