Comments on: The Golden Rule of Unit Testing

By: Brian Lavender

Brian Lavender — Thu, 14 May 2009 09:38:16 +0000

I have to apologize. I was being sort of esoteric. When you mentioned sml, it made me think of my programming principles class at Sac State, where we used Bertrand Meyer’s book “Introduction to the Theory of Programming Languages”. which in turn made me think of his language Eiffel and Design by Contract. Honestly, I haven’t used DbC much in practice, so I can’t speak from real experience. I know that DbC is now in Java, .net, and a number of other areas.

Certainly, you make a good point with unit testing.

By: Ville Laurikari

Ville Laurikari — Wed, 13 May 2009 17:56:24 +0000

I certainly use asserts and other similar tools to check invariants at run time, but I’ve never followed the DbC dogma to the point of writing the contracts before writing the code; this may be just because I haven’t used Eiffel. But I have written unit tests before writing the implementation(s), which is kind of the same thing but with a different twist.

As for proving correctness… I’m not a believer, at least not for widespread use in “everyday programming” by the masses. Then again, I also believe that the masses should not be writing computer programs in the first place.

By: Brian Lavender

Brian Lavender — Wed, 13 May 2009 08:15:00 +0000

What about pre, post, and invariant conditions like in Eiffel? Seems that design by contract can build a lot of confidence into the code. I have only briefly played with it, but assuming your code is not influenced or produces side effects, you can prove it correct. I don’t have a lot of experience with it, but I thought I would throw that out there.

brian

By: klaar

klaar — Tue, 12 May 2009 20:31:41 +0000

Does he mean that i should optimize my test coverage to only cover the most important components at an early stage? Very clever.

This comment was originally posted on Reddit

By: Ville Laurikari

Ville Laurikari — Tue, 12 May 2009 17:30:49 +0000

Justice, I completely agree. What prompted me to write this post was the common misunderstanding that a “unit test” is supposed to test the smallest possible unit (a function or method) in isolation. If it’s testing more than that, it’s not a “unit test” but something else.

In my world, a “unit test” is almost always testing the public interface. This appears to also be the viewpoint of the software industry in general, but every now and then I run into trouble with this terminology.

So, before one goes very deep into an argument about “unit testing” with someone, it may be useful to check if you’re even talking about the same things…

By: Justice

Justice — Tue, 12 May 2009 17:15:24 +0000

It’s a long way of saying: write unit tests public interfaces and contractual behaviors; don’t write unit tests for private implementation details or for simple getters and setters.

Harry should have written a few unit tests for the module’s public interface (the single function ‘parse’), testing various scenarios ranging from simple to complex. He should not have written unit tests for the particular way he implemented the interface. When he added in behavior to handle newlines, he should have written some unit tests to check that the newlines bug does not will not reappear later as a regression. When Ethan ripped out the regexes and replaced them with a parser, he should have written some tests specifying that the module can handle character-entities too, thus protecting against a future reappearance as a regression of the character-entities bug.

Of course, while developing a module, one may want to include some test-driver code to check basic parts of the implementation. But these test-drivers are not part of the unit-test suite. They should not be run automatically. They are there only to ease development, and may be deleted at will (because you are using source control, right?).

Unit tests are a way of answering, in precise a way as you are willing to write code for, the question: “What is this public interface supposed to be doing, and does it actually do that?” Unit tests should not answer the question: “How does this implementation work under the hood?”

By: vlaurika

vlaurika — Tue, 12 May 2009 15:13:30 +0000

> What he is describing is making your new code legacy before it is even released because there are many dependencies from test cases. The point is that you should aim to get your test coverage by testing on a level which is the least likely to lead to a lot of obsolete test code after a potential future refactoring. That kind of test code is *helpful* when refactoring, instead of merely obsolete. Testing each function in perfect isolation, as per the Wikipedia definition of unit testing, does not help you when you refactor the code.

This comment was originally posted on Reddit

By: gregK

gregK — Tue, 12 May 2009 15:01:06 +0000

>Most importantly, unit tests make the code rigid. It makes little sense to write heaps of testing code against interfaces which will be changed soon. He bring out an important point. If you are afraid to fix your code because you don’t want to rewrite your unit tests then something went terribly wrong. What he is describing is making your new code legacy before it is even released because there are many dependencies from test cases. I say don’t be afraid to scrap obsolete test cases. Also I agree don’t over do it, if you are still figuring out what you want. Get your ideas straight first then focus on robustness via massive tests.

This comment was originally posted on Reddit