Unit tests specify
There is a lot of functionality (or business logic) that is accidental, meaning that it is not really necessary and it might even be plain wrong, a bug. It happens, a lot. It is hard to know if a piece of code is accidental or not if you do not have a way to express it. A unit test is a great way to express your intent and your “real” functionality. For me, unit tests are specifications. They specify the intended functionality. This is explicit functionality. I love explicit functionality. In fact I love almost anything explicit when it comes to code. I want to read loud and clear what the intentions are. The opposite of explicit functionality is of course implicit functionality. This is the functionality that resides in the code without anything or one to claim its importance. Implicit functionality might always be accidental, and that is why it is so hard to work with that kind of functionality. You do not know if it’s supposed to be there.

Unit tests verify
If all important functionality is ensured with unit tests, you have your safety net. The unit tests verify what you specified. Then refactoring is a dream. Keeping the codebase neat, up to date and clean is easy. To be able to nurture your codebase, through refactoring, you will need this safety net. It verifies your intentions and ignores all unnecessary code.

Unit tests do not test software
This way unit tests ensures that the intended functionality in your classes stays there, and makes it easier to refactor. But it does not check if your system work. It does not verify that you have put it all together the right way. It does not check if everything goes right in the databases, on files or in the user interface. Partly integration tests will do this job for you, and partly manual testing.

Abstractions through OO
When I talk about unit tests, I consider my units to be classes. I also want to stress the point of knowing where to put your logic. Responsibilities should be placed where it belongs, in the right concepts (on the right classes). This is the fundament of object orientation, expressed elegantly through domain driven design. The concepts are the classes. Thus it is very important to verify the logic where it belongs, on the classes. And why should we use classes and separate logic? There are mighty reasons for this, but for now let me just say: to avoid cognitive overload.

You need all types of tests
So, unit tests are there to specify the behavior of the systems concepts (think DDD). This is imperative to be able to refactor the core of your system. But as I’ve said, this is far from enough to test your system. I find integration tests best for testing your software. Tests that are more like acceptance tests, checking a complete path of calls from top to bottom (and yes, I often include the database in these tests). In addition there are things you will not be able to test automatically (that easily). How does the gui look and feel? You need someone to test that too.

To conclude, you need a whole lot of unit tests to lock down functionality. You need integration tests to test your software, and you need people to test gui and other stuff that isn’t feasible to test any other way. And my opinion is that you should do all this before you send it to QA.

-Tore Vestues

Design is the key

I feel stronger and stronger that TDD is all about design, especially if you take the need-driven/mockist-approach (see article reference below). Your system will look different if you create it test first. Apart from the fact that it will be easy to test (never running into detestable objects), TDD-developed systems tend to have lower coupling, which in turn has a positive effect on a systems flexibility, which again is nessecary for applying refactoring.. I could go on.

The article, “Mock roles, not objects”, describes TDD as a design prosess in an exellent way. When I first read it, it really opened my eyes on how to design flexible systems with TDD.

Verification

In his article “Mocks aren’t stubs”, Martin Fowler writes about the difference in using mock objects or not. He finds that (among other things) when using mocks you use behavior verification, while others use state verification.

Fowler argues also that mockist tests couples the tests to implementation since it uses behavior verification. Allthough I do not totally agree on his views on this issue, here he has a good point. The main problem with behavior verification is that the test and the SUT (Subject under test) is tightly coupled together. Coupling between testclass and SUT is no problem when they are coupled together on the expected external behaviour, because if you want to change that, you want to change the test first. But it is a problem if a change that does not change the external contract, will break tests. This means our code is less flexible, and it will lead to more work for every internal change, like a refactoring.

This does not mean that I’m giving up mocking (I still love the way it drives my design), and it does not mean that I will mock less. So, what do I do?

First, I verify external state, if there are any, like I’ve always done in addition to verifying behavior.

Second, some behavior can actually be regarded as a part of the public contract. For instance if an objects is supposed to post three messages to a log-queue, if it receives three notifications, this is behavior, and it can be regarded as public, at least for test purposes. This kind of behavior can easily be tested using mock objects.

Third, for private behavior, I try to be as loose as possible in my expectations. I often use Expect.Any() or Expect.AtLeastOnce() instead of Expect.Once() or Expect.Never(). In these cases we’re not really that interested in the behavior, we’re more interested in controlling the supply of objects to the SUT.

Your tests are your documentation

I’ve been reading alot about how your tests should be the key to understanding your systems behavior. Until now, I have thought that reading actual test code is the key. In one sense it is, if you read the test code, you understand in detail what that test tests. But honestly, no matter how much refactoring you do to make your tests understandable, looking at test code doesn’t really give you a quick overview of what is expected, as a whole, of a class.

But then I suddenly realized that the key is in the test names (method names), not in the test code.  Let the test method names describe the expected behaviour of the SUT, reading those names should be sufficient to get an understanding of the obejcts responsibilites and limitations. This means that all requirements of a class must not only be tested by a test class, it also has to be explained explicitly in the test method’s names.

For links on TDD, go to the links page.

Tore Vestues