Do you think early startup product might be an exception?
Since whole features can be quickly ditched frequentl. Sometimes even complete product pivot.
Since whole features can be quickly ditched frequentl. Sometimes even complete product pivot.
The habit is important. If you don't start, after three pivots you'll have a huge mountain of tests for a system nobody understands. Plus all the wasted time manually "testing".
Tests are so critical for the success of the business. It's fiscally irresponsible to skip.
But if the objective is a professional output, test, test, test.
I also find manually testing to be tedious, so I'd rather spend that time writing code that does it for me.
Sure you can encode all of that as comments, but unless you reread each file when you return from a break, you can’t always trace those thoughts and see where they lead. On the other hand if you “find all references” in your ide or change some implementation so that a test breaks, past-you can save the day with that extra information about what they intended at the time.
Over time you realize that testing truly does not slow down development as much as many people think it does. Maybe devs who just aren't used to testing find it difficult, but after a while it becomes second nature.
The best thing an early startup CTO can do is enforce testing across the board, so people don't just test when they feel like it.
Not my experience. We just built a new codebase, rewriting an older project with typescript and all the modern libraries and conveniences. We spent about 2x more time writing the tests than we did any of the API code.
Tests can be so fiddly and not exactly straight-forward. It takes a lot of time, but that isn't a reason not to do it. But don't suggest it's going to take less time, even in the long run, because it isn't - you essentially have to maintain 2 codebases now, one for the actual code, and one for the tests. Both are points of failure and both can be a time-sink.
The payback for good testing is very fast, especially once you have set it up for the first feature.
Focus on testing the use cases that are important to users, not on covering every single line.
Even if I was doing a one day hackathon I'd probably have some sort of test feedback loop.
I've dealt with P1 bugs that cost the company 100k/minute and still took the time to write a test for the fix because you really don't have time to get the fix wrong and not find out until it is deployed.