

Why To Write Tests For Your Code - lchengify
http://masternerd.lucianocheng.com/5-reasons-for-testing-masternerdposterouscom

======
ZeroMinx
There are obviously many reasons, but to add a couple;

 _Fight regression_

You don't want to fix the same bug several times, do you? When a bug is found,
I first write a test to repeat the bug. Then I fix the code. Now every time I
want to release a new version, that particular bug is tested yet again.

 _The 'quick fix' 5 minutes before launch_

You're approaching deadline, everything is looking fine. Then, just before
launch, a small bug or a tiny new feature has to be added. You can't imagine
that would have side effects, can you? Well, that one bit of code, a small
module that 'never changes', which you haven't looked at for 12+ months,
reacts badly to this change. With good tests in place you catch this before
you hit production problems.

~~~
abstractbill
_The 'quick fix' 5 minutes before launch_

The universe tends towards maximum irony, and you are seriously
underestimating that maximum. Even with 100% test coverage, fixing something 5
minutes before launch is an _awful_ idea. Either delay the launch, or accept
that the bug is small enough to not matter.

~~~
ZeroMinx
Yes, I can/do not deny the power of the irony gods.

 _awful_ idea, yes, I agree, but real world is full of awful ideas. You can
either accept it and adapt, or be drowned by it.

------
wccrawford
More:

Make refactoring easier - I quite often write tests for legacy code if I'm
going to refactor it. It's the only way I can know it's still doing the same
thing. Sadly, this sometimes means doing some blind (test-less) refactoring to
make testing possible, but that's sometimes unavoidable... And still far
better than doing the whole thing blind.

Have more confidence - I use to dread the day we pushed things live. I would
actually cringe while it happened, and just wait for the shit to the fan. The
more tests I have, the less I cringe and the more I enjoy the releasing of
new, better code.

------
gatlin
I am relatively new to HN and have _read about_ but not _seen_ an anti-testing
mindset around here. I imagine this article will stir that debate if it
exists.

Can anyone tell me why they would not want to write tests? I have no biases
here.

~~~
jackpirate
_Can anyone tell me why they would not want to write tests?_

Laziness, ignorance, rapid prototyping, no budget, more important problems...
all the obvious reasons. I can't think of any "good" reasons from an
engineering perspective, only business.

~~~
wccrawford
Rapid prototyping is the best anti-testing reason I've heard yet. I even
halfway agree with it.

But in my experience, even prototypes can benefit from it.

For me, testing actually makes the whole thing go faster. I spend less time
worrying and more time developing, because I have the confidence that the rest
of my code works exactly like I want it to.

~~~
coecoventures
Totally agree. We're following a lean startup approach and have identified our
MVP and roadmap. Unit testing allows us to ensure our MVP works and that we
have a reliable way to add features per our roadmap and still have a viable
product. This sets the stage for us to rapidly and reliably enhance the UI, as
well, while still shipping on time and getting customer feedback.

------
hxa7241
> In a way, using tests to check code is like designing two trucks and having
> them pull against each other; if nothing breaks, you know they both work.

('bad metaphorical thinking' Dijkstra alert)

This is wrong. If the tests pass, it is entirely possible that _both_ the
original code _and_ the tests are faulty.

------
davedx
I'd love to see an article on unit testing that gives reasons they add
business value, so hackers like us can convince pointy headed bosses that we
should be allowed the budget to write them.

"Improving the quality of our software" is the one I tend to use, but it's so
vague. How will unit testing convert into cold, hard cash is what upper
management want to know.

~~~
raganwald
Feigning incomprehension, I will ask, “Why do you need budget to write them?”

If I am estimating how long the work will take, I am estimating how long it
will take to get the functionality working correctly with X% confidence it
works correctly _when the product ships_. Unless “X” is less than 50%,
automated testing is part of writing the code, not a nice-to-have.

“Improving the quality of our code” does sound vague, kind of like arguing how
many knots are permissible in a plank of wood destined or a kitchen floor.
Instead, I would simply explain that these tests I write are part of writing
the code, and to explain that if management want the code without the tests,
they need to tell me in writing that they are ok with a confidence level
hovering around 50%.

I am not kidding about this number. I may deliver code that appears to do what
it is supposed to do, but my experience is that either it is broken in ways
that a simple QA test doesn’t show, or somebody (somebody else or even me next
week) is going to regress it between now and when the product ships. Automated
tests give me the confidence that it works, works correctly, and will continue
to work correctly.

~~~
cdcarter
"kind of like arguing how many knots are permissible in a plank of wood
destined or a kitchen floor"

Having sat through an hour long lecture on lumber grades in a scenic
construction course, let me tell you, it is anything but vague.

------
qntm
The way I look at it, there is only one reason to write tests: _to assure
shippability_.

Everything else is a pleasant bonus. It amazes me that so much can be written
without even touching on this.

