3 ms·

So by that logic is it more pleasing to have a bigger test suite than a smaller one? I'd argue that a test suite should be as small as possible to test the cri

So by that logic is it more pleasing to have a bigger test suite than a smaller one? I'd argue that a test suite should be as small as possible to test the critical areas of the app, at least until the app ships, and then new tests should be added as the app takes a more definite shape, etc. How much fun is it to refactor a test suite b/c the product changed substantially and you are now mired in the cognitive dissonance of a very un-agile (slow) change or in a bunch of broken tests.

boyter 16y ago
Wouldn't that indicate that you have written bad tests to begin with? My personal experience is that if you have followed TDD to the letter then breaking tests are a good thing. If however your tests are breaking when you change unrelated things then you have brittle tests which are bad.
- techiferous 16y ago
  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).

boyter 16y ago

Wouldn't that indicate that you have written bad tests to begin with? My personal experience is that if you have followed TDD to the letter then breaking tests are a good thing. If however your tests are breaking when you change unrelated things then you have brittle tests which are bad.

techiferous 16y ago
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).