

Why Unit Tests Matter and How They Will Save You Time - gscott
http://www.ddj.com/development-tools/208403755

======
maurycy
By the way, could someone provide any real statistics about unit tests?

I've already read quadrupillion times that they're great because they lets you
save time, provide a testing history, simplify maintaince, and take care about
your daughter. Let's say that I'm convinced. But still, I would like to see
some numbers, some carefully performed study that proves that such statements
are right.

The problem is that they're very confirmation bias prone. People see a
situation when the unit tests found a bug, but they don't see thousands of
situaton when a bug wasn't found ("hey, it does not make sure your code is
correct"), or pointless hours spent on rewriting the tests because the code
changed significantly. Though, could be I'm prone to antybuzzwords and
antyhype bias.

~~~
nostrademons
"when a bug wasn't found ... or pointless hours spent on rewriting the tests"

Both of those are very real problems with unit tests. You should expect that
thoroughly unit-testing your code roughly doubles the amount of time you need
to spend on it.

The real benefit of unit testing isn't in catching bugs, though: it's that it
lets you refactor without worrying about breaking things. Without a complete
set of automated tests, most companies simply institute a "Don't touch that
code; something might break" rule. Then their codebase becomes a sprawling
mess, nobody touches it because they don't know what'll happen, and nothing
ever gets done.

Virtually all development "best practices" do not speed you up: most slow you
down by a significant amount. The point of them is so that you can make any
forward progress at all. There's sort of a brick wall that happens when a
piece of software gets bigger than one head can contain, and unless you adopt
techniques to mitigate that, you'll find that you can't do anything other than
rewrite the code from scratch.

~~~
maurycy
If your application is so large, it would be good to ask first if it really
needs to be so. We favor small methods, which do only one thing. We favor two
pizzas teams, which are small. Why large applications are not considered
harmful? You might want to move some of your functionality into different
modules, libraries or separate applications.

The false premise lying behind the 100% coverage philosophy is that instead of
avoiding bad practices and being careful with your every step, trying to make
things as obvious as possible, tests let you not to think about it. You can
stop worrying. They work like a committee, freeing you from responsibility.
Especially if you're a mediocre programmer looking for constant excuses.

Articles about tests are mostly abstract. Kool-Aid's hectoliters why tests are
great, yet nearly zero discussion how to get them right. Tests are not created
equal. I follow Rails blogosphere, which is a very test oriented community,
and I don't remember too many, if any, writings about how to write good tests.

For instance, let's raise confirmation bias again. People usually write tests
to make sure the things work as they think they should. I've not seen too many
agressive tests that tried to check exteme cases, to, literally, falsify the
method. If you deal with things more complicated than Rails controllers, it
becomes the real issue.

I also try to perceive tests in terms of ROI. If you don't plan to make your
application big, why bother? If you don't plan to do any non-standard things,
why bother? If it took five minutes to come up with an immediate and obvious
solution, why bother? If you change your frequently ("writing is rewriting"),
why bother right now?

I'm not saying that tests are all bad. I just don't get the whole hype, saying
"write tests, be happy" without raising all risks involved.

~~~
nostrademons
"If you don't plan to make your application big, why bother? If you don't plan
to do any non-standard things, why bother? If it took five minutes to come up
with an immediate and obvious solution, why bother? If you change your
frequently ("writing is rewriting"), why bother right now?"

Don't bother.

When one of my programming mentors was explaining unit tests to me, she said
"They don't have to be a huge deal. Just enough to let you have confidence in
your code." That's the real issue - having confidence that your code does what
you think it does and will continue doing so.

I have a pretty simple litmus test for when I need unit tests: if I ever have
to say "Well, it _should_ work..." then it's time to write a test and find out
if it really does.

But I don't unit test things like Django models or CSS positioning, unless I'm
doing something funky or complicated. I _do_ unit test a lot of my JavaScript,
since doing anything non-trivial is complicated.

------
bhb
Interesting article, but the author seems to assume that unit testing == TDD.
I think weirdness of "write your tests first" is one reason people initially
resist writing tests ("I can't do exploratory programming!")

I write lots of unit tests (and find lots of value in writing them), but I
only do TDD about half the time. Generally, when I am writing a new feature, I
write my tests after it's reasonably stable. However, when fixing bugs, I
usually do TDD.

~~~
jamongkad
" I think weirdness of "write your tests first" is one reason people initially
resist writing tests ("I can't do exploratory programming!")"

That is one of my main gripes with Unit Testing and it still is. Similar to
you I practice TDD like what? not even half the time? Well nowadays I do. But
I have to practically force myself to do it. Perhaps give or take a few years
I'll have it ingrained in muscle memory.

------
vikram
I write unit tests after I am happy with the function. By writing the code in
a functional way and building code a construct at a time which I test as I
write it. I think I get best of both worlds.

