That’s impressive, but I feel like you are avoiding the main criticism in that link. Testing doesn’t matter at your stage. Imagine if you spent a bunch of time perfecting the human resource procedures for your websites, it’s too early to think about that. Maybe that is hard to internalize since it was your job for so long
>Testing doesn’t matter at your stage. Imagine if you spent a bunch of time perfecting the human resource procedures for your websites, it’s too early to think about that. Maybe that is hard to internalize since it was your job for so long
Ah, I see what you're saying. I respectfully disagree.
For me, testing earns back time invested very quickly, often before I even commit a changelist. I would write more tests if I were working for a large company or I was maintaining a mature product, but I don't buy the idea that zero is universally the correct number of tests for any early-stage product.
My E2E tests and CI routinely prevent me from breaking major functionality in my websites and APIs. It seems like a no-brainer to spend an extra 20% of my up-front development time writing automated tests to catch those instead of discovering the breaks after the fact, patching it, then testing all the functionality manually.
