

Regarding Unit Tests - noaharc
http://winterazalea.livejournal.com/136061.html

======
hakunin
Instead of focusing on how (not) useful automated tests are, we need to admit
one thing. They are often a daunting time sink, for whichever reason. You can
make them habitual, but it's hard to sustainably enjoy writing them. You wish
they took less time and gave more benefit. I bet if that was the case, we
wouldn't have so many debates on whether tests are needed.

In the recent story about human-powered airplanes they finally came up with
the right question: "How can we make the flying machine easy to fix when it
crashes?". Imo, here we need to ask the right question as well: How can we
minimize the time consumed by test-writing while maximizing their usefullness?
Maybe we should drop the practice of 1 assertion per test, or the notion that
tests are also documentation. Maybe we should embrace integration tests. Maybe
not. Maybe we should strip all the cruft around the point of tests "it helps
you think, it documents your code, it leads to better design" and get back to
the roots. Tests are there to make sure that critical parts of your code keep
working. That's it. It's better that we sustainably write useful occasional
tests for critical code than lie to ourselves about how disciplined we are,
burn out, and condemn the whole thing.

------
andrewcooke
it sounds like he(?)'s a relatively new programmer whose jumped from a place
where they don't test at all to somewhere where they are forced to be written
before code.

fact is, they're a tool. i don't write tests for everything. and i don't care
much if they are unit or integration or regression or xxx tests. i write tests
where i know they will help (and i write my code so it can be tested, but how
can you separate that from "good design" anyway?). that comes from experience
and requires freedom - the freedom to decide when to use them and when not.

which sucks if you're new and clueless and in a shop with "rules". but then
the rules are there because you're young and clueless and this is your first
job where you get to write tests...

if the poster is reading this, all i can suggest is: suck it up, get better,
and get to the point where you know what to do, and where you're good enough
to get a job where you're trusted. it will happen with time, if you stick at
it.

------
boyter
Looks to me like he went from one extreme to another and managed to get burnt
in the process.

I am sure someone else is going to say this but tests are a another tool
towards software quality. They are not the only tool to achieve this goal nor
are they a silver bullet.

They really save you when six months down the track and you are refactoring a
fairly hairy piece of code you hammered out to fix some critical bug.

This is where I find myself. All critical paths have unit tests (which helps
enforce a clean design) and as such I am not afraid to make sweeping changes
to the codebase.

------
sixtofour
"IV) Use the Intel Model. Do not have one product that you iterate on
indefinitely. Rather, start over from scratch every so often. ... Intel learns
its lessons and carries them over in spirit to the next model each and every
time. Even though they start designing the implementation from scratch each
time, they in essence remember the important bits from before, and have a
Science for reproducing their implementation from their principles and learned
lessons."

The whole article is worth thinking about, but this is the gem for me.

------
lyudmil
I think there are three more reasons to do unit tests I wish the author had
mentioned:

1\. Not only do they prevent you from messing your code up because you forgot
how it actually worked, they prevent you from having to _think_ about how and
whether you've messed something up. I find this to be a creativity boost.

2\. By helping you maintain the same level of quality, they ensure that if you
don't add any new features but keep fixing bugs (and unit testing the fixes),
your bug-count will go down. That's a good property for a system to have.

3\. They give you the freedom to quickly and securely change your design,
which in turn means you can keep improving quality, which in turn means you
maintain higher productivity in the long run.

With this in mind the it seems the author's suggested alternative approaches
fall short of what unit tests can do.

------
alok-g
An interesting quote from the article:

"I will say that I prefer Unit Tests to none when I'm forced to work with
stateless programmers who can't remember what they were programming two weeks
ago and operate without a design. They'll see a bug, tunnel vision on it, and
wreck the whole code base trying to rewrite things to fix it. What's fun is
watching them oscillate between two bugs over time without realizing it,
fixing one while breaking the other, and vice versa."

I have certainly come across cases when programmers created >1 bug while
fixing one (chain reaction!), but never oscillations like the author mentions.
Has anyone else witnessed this? If so, can you provide an example?

------
sharkbot
I find unit tests are useful due to a property they share with types, paired
programming or formal specifications: you are forced to describe your program
in two different "languages", and therefore have to think deeper about the
problem. All of the aforementioned methods force one to code, as well as
describe the intent behind the code. E.g., a unit test forces the programmer
to describe the relationship of input/output, while the code describes the
actual mechanism of linking input with output.

Code is always the most fundamental "description" of a program, but all the
methods have some descriptive power. The process of having two separate
descriptions should lead to a higher quality output, as divergences between
the two show a possible misunderstanding of the problem, and hence a source of
bugs.

