Today’s article is something a little special. It’s the first article where I use code from my current personal project for examples. You will be getting “real world” examples and not silly, made-up examples like my Scientist and Pen example in my factories article.
There’s a fair amount of ideas out there about what you should name your unit test methods. Until recently, I had followed a variation of BDD‘s naming scheme, “shouldDoSomethingWhenGivenSomething”. BDD-esque naming is still what I consider the best naming scheme that I’ve seen out there (what I’m going to show you in this post doesn’t count for some interesting reasons that may or may not be clear to you when you’re done reading it). It’s certainly not bad, but I’ve got a few bones to pick with it, and, eventually, a solution.
Problem #1: Difficult Searching/Distinguishing
First off, BDD’s naming convention lends itself to long names that have repeated parts between different tests. For example, “shouldThrowMyExceptionWhenGivenInvalidParameter1” and “shouldThrowMyExceptionWhenGivenInvalidParameter2”. This can be a pain to deal with when a test suddenly goes red and you have to find it among all your other test methods by name in order to see what might be the problem. Continue Reading