The Start-Up Trap

Startups _are_ different:

1. What you are doing starts at 0 value. 2. You can (usually) break it and it's ok. 3. You need to change stuff a LOT to figure out something that someone wants to use, rewriting tests makes that slower.

Every test case you write has a cost: It verifies that something of unknown value works. What if the value of that code is 0? Well, you just doubled down on something useless.

There are no absolutes in software development, but how we did it was have uncomfortably too few test cases when something is new, change the product for a while until someone actually wants to use it, then add a bunch of tests until we know it works from there on out.

And I hesitate to add: Also we work in Java so a bunch of testing comes for free, so there's that.

Since when does one have to work on a successful startup or have a good exit to have opinions on the best way to start projects? I work at a BigCo and have started a couple of projects.

Not for reasons of finding bugs – though that is often a nice side effect – but because once I have decent test coverage I don't need to look at the application anymore. Being able to run the tests in the background to verify my work is sane, while I move on to the next feature in parallel, I find, is considerably faster than the code/build/review cycle you find yourself in without a decent test suite.

My own performance, being a limited commodity, is the most important factor and I find tests help me increase output, not slow it down as you suggest. They are certainly not a panacea though. As always, use the right tool for the job.

I think his whole crusade grew out of being frustrated by an insanely crufty and rigid waterfall process that he saw on enterprise projects he worked on in the 80s and 90s. I don't actually know what he worked on, but I imagine it was the kind of projects where they would throw a couple dozen C++ programmers at various subsystems conceived by an architect, code like crazy for 6 months, and then spend another 6 months attempting to flush out bugs with human QA.

Post-XP/Agile I think it's easy to forget that automated testing was not a standardized practice 20 years ago. Everyone had their own methods of doing it if they did it all. To me, TDD was a phase I went through for developing good testing discipline. The power of TDD in my mind is a training tool to develop strong testing skills. If you are not good at testing, there is always a high burden to write tests, so you do it less because it doesn't seem worth it. However if you are very good at writing tests, then you find that a lot of the time you can crank out a test/spec suite in about the same amount of time as manually testing. The benefit of course is that then you have documented and programmatically verifiable proof of your intention being fulfilled. Practicing TDD is a way to force yourself to learn how to test things in all cases, after you've mastered that you can step back and consider what the truly valuable tests are without having your judgement clouded by overweighting the relative difficulty of producing certain tests.

Now that I'm good at testing I almost never do true TDD, but I never produce any long-lived application code without some kind of test coverage.

But I think your comment misses out on the middle ground in common dynamic languages. What a good test suite does is reflect on code to document the intention of the author and provide an automated means of verifying that that intention was in fact fulfilled. Granted, test suites have bugs too, so a passing test does not guarantee there wasn't a bug, but the fact that you have two (hopefully) orthogonal descriptions of the code in question means that you stand a much better chance of actually teasing apart what happened when something blows up down the line. I've been saved and emboldened by my test suite enough in Ruby that I now consider it irresponsible not to have complete-ish coverage. I just see it as good code hygiene.