Dave Donaldson

Be Descriptive When Naming Unit Tests

Saturday, August 04 2007

I don't know about you, but it drives me a bit crazy when I find a unit test whose name doesn't tell me what it's testing. I'm sure you've seen what I'm talking about:

- DoSomethingTest1()
- DoSomethingTest2()

Those names don't tell me anything. All it tells me is that there are two tests that, um, do something, but neither tell me what they are actually testing. I prefer to be very descriptive when naming unit tests, even if it tends to produce rather long method names. For example, let's say I have a requirement to search for orders and I need to be able to find them by order number, either as an exact match or by using wildcard searches. As such, I would write the following unit tests:

- FindOrdersByNumber_OrderNumberMatchesTest()
- FindOrdersByNumber_OrderNumberDoesNotMatchTest()
- FindOrdersByNumber_OrderNumberBeginsWithTest()
- FindOrdersByNumber_OrderNumberDoesNotBeginWithTest()
- FindOrdersByNumber_OrderNumberEndsWithTest()
- FindOrdersByNumber_OrderNumberDoesNotEndWithTest()
- FindOrdersByNumber_OrderNumberContainsTest()
- FindOrdersByNumber_OrderNumberDoesNotContainTest()

Yes, these names are a bit lengthy, but at least I (and anyone else) will know what each one is supposed to test at first glance without having to inspect the code of the unit test to understand it.

Unit tests are code and are an integral part of your application, even if they don't get deployed anywhere. Treat them as such by giving them proper names.

Post your comment

Name

Mail

Website