After your loving grandfather, of course.
Just kidding.
Naming tests correctly is a skill that can determine the effectiveness of your tests. Yes, really.
Effective tests do two things: warn you on the first sign of trouble, and help you fix the problem as soon as possible. The first one everyone knows intuitively. The second one? not so much.
But think about it: What’s the first thing you look at when the run turns red? The failing test name. If you called it “test1” it’s not that helpful. And by helpful I mean: I need to fix this quickly, and if possible, without debugging.
So obviously, naming is very important. What are the rules for proper naming?
Rule #1: Know what you’re testing
If you don’t, don’t bother with a name yet. What method is under test? What do you expect to happen? Under what circumstances? You must at least have this understood before writing a single line of test code.
Rule #2: Make it human readable
See, while your test runner can tell the difference between “pass” and “fail”, it doesn’t have a clue about the meaning of the test name. It will be up to you, or another human on your team, that can see what’s going on. The name tells it all, mostly for us bipod beings.
Rule #3: Make it as long as you need
That’s what she said! About test names, of course. Put in as much information to make help the poor soul who happened to be on watch when the test failed. Instead of him trying to guess the hidden meaning, say it all. I use a convention of MethodUnderTest_SpecificScenario_ExpectedResult, which usually works, but on occasion may require more parts. You can use the BDD convention of Given_When_Then, or any other way that can help the reader understand what just didn’t work. Don’t skimp on characters!
Rule #4: Give it personality
Some uniqueness required. You may get the root of the problem by checking not just which tests failed, but also which still pass, comparing the different scenarios. If you named your tests with proper distinction, you can tell by looking at the different names of the tests related to our culprit. If you’re using Isolator V7, you get all that info, in one place, right there on the code!
Rule #5: Give it a test
If the test failed on your watch, you can make sense of it, I’m sure (hidden sarcasm included). But what if it’s not you? Grab someone by the ear and make them read the name and tell you they understand it. If you pair-program you’ll get that for free.
There you have it. 5 simple rules for test naming heaven.
My heaven at least. Now it’s your turn.
Are there other rules you follow? What convention do you use? Tell us in the comments!
Start unit testing. Download Typemock Isolator.
