Naming your Unit Tests

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.

Advertisements

2 Responses to Naming your Unit Tests

  1. Aleksey Berezan says:

    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.

  2. I use class per method approach. Quick overview: Every class translate to test fixture (obvious). Every method translates to nested class. Every test method is prefixed in descriptive manner (as you mentioned). Example:

    [TextFixture]
    public class WriterTests {
    public class AppendMethod {
    [Test]
    public void ShouldRaiseNullArgumentException() {
    }
    }
    }

    The best part is NUnit translation of such structure: WriterTests_ AppendMethod_ ShouldRaiseNullArgumentException.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: