Member-only story
How I keep my test names short and functional
There are plenty of topics in software development land that cause passionate (and sometimes almost religious) debates. Tabs vs spaces is most definitely one of them. And in .NET land there’s always some team debating about the use of _
in private fields and var
for local variables. Fortunately, naming unit tests isn’t such a hot potato and a lot of variations are widely accepted. But I still care about having functional and self-explanatory names.
I never really liked the idea that (I think) was introduced by Roy Osherove in his famous book The Art of Unit Testing. He proposed to use a convention like [UnitOfWork]_[StateUnderTest]_[ExpectedBehavior]
. This results in test names like Sum_NegativeNumberAs1stParam_ExceptionThrown
. Although I totally dig the use of underscores, those names are way too technical and cryptic to me. As I wrote in an earlier post, I see the name of the test as an important piece of information. For me, it should explain the functional scenario that the test is trying to assert and not a description of how the test behaves.
For a long time I have preferred the more functional When_[scenario]_it_should_[expected_behavior]
. For example When_the_same_objects_are_expected_to_be_the_same_it_should_not_fail
. It’s functionally correct, but I’m seeing this style more and more as noisy and verbose. So let’s look at how we…