Reasons Why You Should Write Proper Tests | Hacker News Reader

Reasons Why You Should Write Proper Tests

laceysnr.com

23 pointsColinWright24 comments

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.

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.

The coverage cheat is for the platform. I don't control the metrics so sometimes working around them is necessary. I would never fudge something to meet a personal standard, my standards are against nonsensical metrics.

Top reason is documentation. So future readers can read about your intent and understand how the code functions. "Knowing your code works" is just validation that your documentation is true to what the code says, which is one reason why we prefer testing to comments.

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.

When given a list of prototypes to code, writing the tests before starting helps me figure out specific edge cases and think about all the details the functions have to do before starting to code. Then, once I start coding the functions, it easily flows out and doesn't need as much refactoring afterward.

However, it's true that when refactoring and changing a lot of details here and there, I prefer to return type those tests afterward instead since a small change in a function can require a lot of change in the tests.

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.

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-...

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.

The advantage to writing test first is that it allows/forces you to test the test.

If you write the test before you've written the code, then you'll be expecting the test to fail (in a very specific way) the first time it is run. By observing this you ensure that the test actually exercises the application code that you intended.

If you write the test after you've written the code, then you'll be expecting the test to pass the first time it is run. However if there is a bug in the test, it may pass for the wrong reason - e.g. if you forget some part of the test setup that causes the relevant application code to get skipped entirely.

Biggest advantage: they actually get written. I've seen so many lines of software ship without coverage just because the test were not written beforehand.

There are advantages to TDD. It forces you to use your code as you write it, which is a very good way to ensure you have a reasonable API. For example, if you hate writing your tests, then there may be something wrong with your code. It also ensures that you have /some/ tests, and bad tests are better than no tests.

But TDD is really about reaching a good design, not about creating useful tests along the way. One of the reasons is exactly what you state. The unit tests that are created in the course of TDD are extremely tied to the particulars of your implementation, and end up being a maintenance pain point in a large application. It is important for your tests to survive a refactor without needing to be changed. So, it is not uncommon for tests created in the course of TDD to be thrown away after you write some good integration tests / feature specs / whatever you'd like to call them for your code.

TDD is not, however, the only way to get to good design. You can also use behavior driven development (BDD) -- which is similar. Or you can just get in front of a whiteboard. Whatever works for you.

At the end of the day what matters is getting to good design and good tests in a way that's efficient and enjoyable for you.

> Otherwise I have to do too much refactoring every time I change a function's name or signature.

It's 2013. Your editor of choice can do this for you.

The best design tends to be emergent; http://c2.com/cgi/wiki?WhatIsAnAdvancer

Writing the tests first forces you to think about how a given interface will actually be used, which tends to lead to better code, because you're writing an interface that makes sense for the client rather than for the called code. In turn that means better encapsulation. It's probably possible to do this in the abstract, but if you're writing the test code anyway it doesn't cost you anything.

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.

> 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.

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.

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.

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.

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?

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!

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.

Man, code coverage is a horrible metric.

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

Reply on news.ycombinator.com