3 ms·

Imagine an early version of a web app. An experiment. It's pre-product-market fit, even pre-problem-solution fit. Things are going to change...a lot. For ex

Imagine an early version of a web app. An experiment. It's pre-product-market fit, even pre-problem-solution fit. Things are going to change...a lot. For example, you decided to rename "widgets" "fooblats". You have to change all of your tests that referred to widgets. This doesn't mean you have brittle tests; it means that what was being tested has changed. This early in the game a good testing strategy may be to write no tests. It all depends.

grandalf 16y ago
This has been my experience. Tests can add some extra cognitive dissonance / friction when it comes to really being agile with your early concepts and approaches. Tests are great when you have a clear spec and you just have to keep the app reliable as you make minor iterations. Or when you're doing something so complex that it's hard to keep in your head at once (this is, I think, the most fun TDD). I think for most web apps a simple integration test that verifies that pages don't error and that basic forms work properly is going to be far more valuable than a bunch of code that tests very simple usages of underlying library code (which is sadly what many test suites I've read for web apps actually do).