97 Things Every Java Programmer Should Know

Chapter 66. Program with GUTs

Kevlin Henney

So you’re writing unit tests? Great! Are they any good? To borrow a term from Alistair Cockburn, do you have GUTs? Good unit tests? Or have you landed someone (future you?) with interest-accumulating technical debt in their testbase?

What do I mean by good? Good question. Hard question. Worth an answer.

Let’s start with names. Reflect what is being tested in the name. Yup, you don’t want test1, test2, and test3 as your naming scheme. In fact, you don’t want test in your test names: @Test already does that. Tell the reader what you’re testing, not that you’re testing.

Ah, no, I don’t mean name it after the method under test: tell the reader what behavior, property, capability, etc. is under test. If you’ve got a method addItem, you don’t want a corresponding addItemIsOK test. That’s a common test smell. Identify the cases of behavior, and test only one case per test case. Oh, and no, that doesn’t mean addItemSuccess and addItemFailure.

Let me ask you, what’s the purpose of your test? To test that “it works”? That’s only half the story. The biggest challenge in code is not to determine whether “it works,” but to determine what “it works” means. You have the chance to capture that meaning, so try additionOfItemWithUniqueKeyIsRetained and additionOfItemWithExistingKeyFails.

Because these names are long, and also aren’t production code, consider ...