
Reasons Why You Should Write Proper Tests - ColinWright
http://www.laceysnr.com/2013/04/three-reasons-you-should-write-proper.html
======
tellarin
The top reason is indeed Knowing Your Code Works.

Be it because requirements keep changing, new features are added, many people
working on the same code, refactoring, whatever... Having good unit and
functional tests catch a huge amount of problems that would be hard to find
latter.

The other two points are pretty minor in my view.

And the suggestion to improve code coverage is just cheating. There's no
excuse for that. Either don't track stupid metrics, don't add unnecessary
catches, or properly test exception code.

EDIT: Clarified text.

~~~
gav
Not just knowing your code works, being able to capture what the code is
supposed to do for the next person that comes along.

For example, this week I've been working on refactoring some code that had
some performance problems. Digging into the code I found a lot of confusing
logic and had to waste a lot of time stepping through the code trying to
understand what it was doing.

If there were unit tests, I could have treated it as a replaceable black box.

------
wting
Can anyone explain the advantages of writing unit tests before vs after
certain sections of code has been finished?

I use unit tests, but only after the code's finished or there's a good
stopping point. Otherwise I have to do too much refactoring every time I
change a function's name or signature.

Maybe TDD is forcing you to architect the program in the beginning, but I find
it cumbersome because stuff changes so much throughout the course of finishing
a project.

~~~
joshuacc
Some points from a recent presentation I gave on the subject.

Writing tests first:

* Leads to better code design by encouraging smaller units of code which you can combine to achieve your larger goals.

* Having tests/specs lets you refactor with confidence.

* Writing the specs first means that they are going to be more complete, so you can have more confidence in them.

* Since you saw the specs fail, you know that they can fail. If you only test afterwards, you don't know if it's passing because your code is good or because the test is bad.

* The more confidence you have in your tests/specs, the faster you can improve your existing code.

~~~
eeperson
I feel like a lot of these points are more about just having tests rather than
writing tests first. Also, I think some of these points only make sense if you
already have a pretty good idea of what you are going to write. More
specifically:

1\. This may be the case but I don't think this requires that you write your
tests up front just that you don't leave all of your testing until the very
end

2\. This is just about having tests

3\. I don't really see why writing your tests up front would make them more
complete unless you already know exactly what you want to build. I find that I
often come up with most of my edge cases while I am writing the code.

4\. In many cases, if you tests before you still don't know if your tests pass
because of your code is good or because the test is bad. Many tests, up front,
fail for very obvious reasons (such as the function you are testing simply
doesn't exist yet). Just because they fail in the beginning doesn't mean they
are good tests. What you actually want is mutation testing [1]. Testing up
front is just a really crude version of this. I usually do mutation testing
manually by removing the code I am trying to test, at the end, to ensure that
my test fails if it is not there.

5\. Again, just about having tests

Ultimately I think you want interactive testing development. Write some code,
write some tests, repeat. The actual ordering of the first 2 steps needs to be
decided on a case by case basis. Writing all of your tests up front can be
awkward. Writing all of your tests at the end is sometimes nearly impossible.

[1] [http://dev.theladders.com/2013/02/mutation-testing-with-
pit-...](http://dev.theladders.com/2013/02/mutation-testing-with-pit-a-step-
beyond-normal-code-coverage/)

~~~
joshuacc
I agree that many of these points are about having tests. But my observation
has been that if tests aren't written first, they either aren't written at
all, or they are written half-heartedly.

------
taeric
This seems a hollow platitude. Might as well have "Reasons you should write
proper software." I mean, there can be little doubt that you should.

Don't get me wrong, I am incredibly sympathetic to the problem. I just have
not seen incredible evidence that one can get better software, just because
one wrote tests. Same for types. (Which, I realize, can be seen as a form of
tests.)

The point I keep flirting with is that learning to write good testable code is
just as hard as writing good usable code. One does not prevent the other any
more than one causes the other.

------
zalew
> Coverage for test methods on Salesforce.com is calculated per line, which
> means if you swap this:

> for this:

> you'll start to see those coverage numbers rising

I'd rather focus on better coverage of the most important elements than waste
time on such irrelevant stuff. I got a lot of tests that don't increase the
coverage factor, so what. Tools are meant to work for you, not the other way
around.

~~~
laceysnr
Zalew, that's a great point but in the force.com environment you must have 75%
coverage and as /wrote, I err on the side of caution in my code which can cost
me in terms of %. I don't like to change my code for the sake of tests, but
layout is another matter.

~~~
NateDad
You're using layout to cover up the fact that you're not testing the _most
important line in that function_.

Error handling should be the FIRST thing you test.

~~~
laceysnr
I test most, but like l said I tend to be over cautious such that some
exceptions are not mine to throw, as in only major platform issues will
generate them, and I refuse to add logic to the main code to facilitate tests.
On some platforms I would be in complete agreement with you but Force.com has
it's own specific peculiarities.

------
rco8786
I agree with you over-arching theme...write good tests. So why would I write
tests that verify property getters and setters? Why would I write more inline
code just so my coverage % goes up?

~~~
laceysnr
It's platform specific, Salesforce requires a 75% minimum to deploy to
production so really you want it to he as high as possible. That part of the
post in particular was for Salesforce developers, I wasn't anticipating it
being seen by so many people outside of that community!

------
jrabone
Test coverage is a pain, but if you don't cover your exceptional cases the
chances are good that your best bugs will be hiding there.

For example, some HTTP client implementations require you to consume any HTTP
entity to avoid leaking connections and/or exhausting a finite connection
pool. If you missed a ... finally { } block but otherwise do the right thing
with your exceptions, you're storing up trouble there.

------
NateDad
Man, code coverage is a horrible metric.

------
stevebot
This read was worth it just for the trick about try/catch blocks

