

The Great Benefit of Test Driven Development Nobody Talks About - boyter
http://www.wausita.com/2010/08/the-great-benefit-of-test-driven-development-nobody-talks-about/

======
orangecat
Unit testing is good, but I disagree with that reasoning. All else being
equal, less code is better.

~~~
apu
Yeah this is completely backwards to me -- do you want the illusion of
progress? Or progress? Often they are mutually incompatible.

~~~
boyter
Just out of curiosity how are more tests (assuming they are useful tests) the
illusion of progress? They provide value if they are well written, so they are
progress are they not?

~~~
compay
Tests are of course very important, but when the coder begins to fetishize
testing and write tests for the sake of writing tests, rather than to help
pursue the project's goal, then it becomes a problem. I've been guilty of this
earlier in my career and have seen quite a few other people do it too.

~~~
walkon
That's not a problem with the methodology, but with the person trying to
practice it.

~~~
compay
Yeah, that was pretty much my point.

------
mkramlich
Of course, one can get the same feeling of success and progress and
accomplishment by just writing the actual needed application code, without
writing any test code. And you'd have the added bonus of producing more
enduser perceivable features in the same block of time.

------
grandalf
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
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
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
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).

------
rlpb
Tests are great. But a lot of my coding is experimental and not all of it ends
up in production. Writing tests take time. If I wrote tests in advance, then a
lot of experimenting wouldn't get done. So I often tend to write tests
afterwards.

My reward? When an experiment is a success and the new feature works. My
second reward is when the feature ends up in production, which can only happen
after tests are written.

------
stretchwithme
Good point. More code that does more work for you.

To me, that's the coolest thing about programming. You create something and
send it out into the world and it creates things too.

------
d0m
I don't agree with what I will say but: If you like so much writing code, you
could, well, write code instead of tests.

Programming example:

while true:

write tests

write code

run tests

vs

while true:

    
    
      write code
    
      write code
    
      write code
    

Oh, you can also optimized that code with:

while true

    
    
      write code.
    
    

or (while true (write code))

Ok, I think I like writing code, not tests.

(Oh, and btw, how do you test, (while true (write code)) ? )

