
Unit Testing Sucks - sutro
http://www.contrariansoftware.com/2008/11/unit-testing-sucks.html
======
Allocator2008
I have to respectfully disagree here, having done a bit of unit testing myself
(JUnit, XMLUnit, CPPUnit). I think the better way to approach unit testing is
have a resource on your team dedicated to unit tests, that way, one does not
have to write unit tests for code oneself has written. I think I sense that is
the big gripe, that writing unit tests on top of the deliverable takes time
and is "boring". I worked at a place where I was on the development team, but
my sole task, or primary task at any rate, was writing CPPUnit unit tests. I
actually enjoyed it alot personally, found lots of bugs that never would have
been found otherwise, and the QA department "felt better" knowing the
deliverable had been unit tested before being delivered to QA. So, having done
unit testing myself, sure I am "biased" but I think it makes for more stable
deliverables to QA and therefore speeds up the whole QA cycle as a result. But
probably ideally I would agree that having a different person write unit tests
than the person who wrote the code being tested is good, in terms of not
adding more work to an already over-worked developer.

~~~
queensnake
My understanding (and even experience) is that, to _get at_ everything you
have to break your code up more than you might otherwise. Thus you have to
_be_ the developer to write unit tests.

~~~
stcredzero
He's missing the point you've just alluded to: in order to unit test
everything that could break, it needs to be written in a way that you can get
at everything. In general, the more easily testable code is the better
designed code. So, if you're doing Test First development, you will write
better designed code our of sheer laziness.

In my experience, when developers decry writing unit test code as boring, they
are:

1) Usually writing their test afterwards, so they've already gotten the reward

2) Have bad design habits (usually solitary programmer habits) and so find it
a real drag to imagine tests for their code.

Also, the article's understanding of the benefits of unit testing are pretty
shallow. The way Unit Testing increases quality is much the same way code
reviews and formal methods increase quality. It is the same reason we have
double-entry accounting, or why people tell you to read your writing out loud
to proofread it. If you make a point of checking yourself in a distinct,
separate step, that cognitive separation makes you less prone to glossing over
your errors.

Unit testing is not a magical elixir and isn't perfect by any means. But the
author doesn't really contribute to the discussion.

