Question

I would like to know from those who document unit tests how they are documenting it. I understand that most TDD followers claim “the code speaks” and thus test documentation is not very important because code should be self-descriptive. Fair enough, but I would like to know how to document unit tests, not whether to document them at all.

My experience as a developer tells me that understanding old code (this includes unit tests) is difficult.

So what is important in a test documentation? When is the test method name not descriptive enough so that documentation is justified?

Answer 1

As requested by Thorsten79, I’ll elaborate on my comments as an answer. My original comment was:

“The code speaks” is unfortunately
completely wrong, because a
non-developer cannot read the code,
while he can at least partially read
and understand generated
documentation, and this way he can
know what the tests test. This is
especially important in cases where
the customer fully understands the
domain and just can’t read code, and
gets even more important when the unit
tests also test hardware, like in the
embedded world, because then you test
things that can be seen.

When you’re doing unit tests, you have to know whether you’re writing them just for you (or for your co-workers), or if you’re also writing them for other people. Many times, you should be writing code for your readers, rather than for your convenience.

In mixed hardware/software development like in my company, the customers know what they want. If their field device has to do a reset when receiving a certain bus command, there must be a unit test that sends that command and checks whether the device was reset. We’re doing this here right now with NUnit as the unit test framework, and some custom software and hardware that makes sending and receiving commands (and even pressing buttons) possible. It’s great, because the only alternative would be to do all that manually.

The customer absolutely wants to know which tests are there, and he even wants to run the tests himself. If the tests are not properly documented, he doesn’t know what the test does and can’t check if all tests he think he’ll need are there, and when running the test, he doesn’t know what it will do. Because he can’t read the code. He knows the used bus system better than our developers, but they just can’t read the code. If a test fails, he does not know why and cannot even say what he thinks the test should do. That’s not a good thing.

Having documented the unit tests properly, we have

• code documentation for the developers
• test documentation for the customer, which can be used to prove that the device does what it should do, i.e. what the customer ordered
• the ability to generate the documentation in any format, which can even be passed to other involved parties, like the manufacturer

Properly in this context means: Write clear language that can be understood by non-developers. You can stay technical, but don’t write things only you can understand. The latter is of course also important for any other comments and any code.

Independent of our exact situation, I think that’s what I would want in unit tests all the time, even if they’re pure software. A customer can ignore a unit test he doesn’t care about, like basic function tests. But just having the docs there does never hurt.

As I’ve written in a comment to another answer: In addition, the generated documentation is also a good starting point if you (or your boss, or co-worker, or the testing department) wants to examine which tests are there and what they do, because you can browse it without digging through the code.