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…

--

--

Dennis "The Continuous Improver" Doomen
Dennis "The Continuous Improver" Doomen

Written by Dennis "The Continuous Improver" Doomen

Dennis is a veteran architect in the .NET space with a special interest in writing clean code, Domain Driven Design, Event Sourcing and everything agile.

No responses yet