Naming your Unit Tests
May 27, 2010 1 Comment
Often I see Unit Tests with the test methods that have the same name as the method under test prefixed with the word “test” e.g. testSubmitApplication. This provides no extra information on which “flow” of the mothod is being tested. Other test method names provide a bit more information by suffixing the nature of the test e.g. testSubmitApplicationWithInvalidCriteria. It better but not much better. A number of IDEs actually allow the developer to generate test method names based on the class under test which in my opinion defeats the object.
Unit test methods should be named in such as way that they provide a clear description of the test. In my opinion the prefix “test” is redundent and should never appear in your test method names unless it is part of the domain vocabulary. For example AppicationSubmittedWithInvalidCriteriaMustRaiseException* is more informative then testSubmitApplication. Providing a more descriptive name also serves to keep a clear focus on the flow under test and leads the devloper to create a test method per flow.
*Please Note that the example method name is a simplification. I would consider the term “InvalidCriteria” a bit too high-level for a real unit test. It should be more specific such as AppicationSubmittedWithNoSurnameMustRaiseException.
hi!
Certainly agreed, informative names are more helpful for understanding, traceability, etc…
What I can to add is that using underscores instead of CamelCasing in test method name makes it more easy-to-read, for instance, “SubmitApplicationWithInvalidCriteriaMustRaiseException” with underscores could look like: “SubmitApplication_with_invalid_criteria_must_raise_exception”(assumed, that “SubmitApplication” is name of method under test). Such names look a bit strange, non-conventional + some IDE’s don’t like them by default(e.g. Visual Studio with ReSharper) but they’re very convenient to read and to work with them, as for me.