Are unit-test names important?

Question

If unit-test names can become outdated over time and if you consider that the test itself is the most important thing, then is it important to choose wise test names?

ie

[Test]
public void ShouldValidateUserNameIsLessThan100Characters() {}

verse

[Test]
public void UserNameTestValidation1() {}

Answer 1

i wouldn't put conditions that test needs to meet in the name, because conditions may change in time. in your example, i'd recommend naming like

UserNameLengthValidate()

or

UserNameLengthTest()

or something similar to explain what the test does, but not presuming the testing/validation parameters.

Answer 2

The name of any method should make it clear what it does.

IMO, your first suggestion is a bit long and the second one isn't informative enough. Also it's probably a bad idea to put "100" in the name, as that's very likely to change. What about:

public void validateUserNameLength()

If the test changes, the name should be updated accordingly.

Answer 3

I think if one can not find a good concise name for a test method it's a sign that design of this test is incorrect. Also good method name helps you to find out what happened in less time.

Answer 4

The name needs to matter within reason. I don't want an email from the build saying that test 389fb2b5-28ad3 failed, but just knowing that it was a UserName test as opposed to something else would help ensure the right person gets to do the diagnosis.

Answer 5

Yes, the names of the code under test (methods, properties, whatever) can change, but I contend your existing tests should fail if the expectations change. That is the true value of having well-constructed tests, not perusing a list of test names. That being said, well named test methods are great tools for getting new developers on board, helping them locate "executable documentation" with which they can kick the tires of existing code -- so I would keep the names of test methods up to date just as I would keep the assertions made by the test methods up to date.

I name my test using the following pattern. Each test fixture attempts to focus on one class and is usually name {ClassUnderTest}Test. I name each test method {MemberUnderTest}_{Assertion}.

[TestFixture]
public class IndexableFileTest
{
   [Test]
   public void Connect_InitializesReadOnlyProperties()
   {
     // ...
   }

   [Test,ExpectedException(typeof(NotInitializedException))]
   public void IsIndexable_ErrorWhenNotConnected()
   {
     // ...
   }

   [Test]
   public void IsIndexable_True()
   {
     // ...
   }

   [Test]
   public void IsIndexable_False()
   {
     // ...
   }
}

Answer 6

Very. Equally important as choosing good method and variable names.
Much more if your test suite is going to referred to by new devs in the future.

As for your original question, definitely Answer1. Typing in a few more characters is a small price to pay for

• the readability. For you and others. It'll eliminate the 'what was I thinking here?' as well as 'WTF is this guy getting at in this test?'
• Quick zoom in when you're in to fix something someone else wrote
• instant update for any test-suite visitor. If done correctly, just going over the names of the test cases will inform the reader of the specs for the unit.

Answer 7

Yes.

 [Test]
 public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {}

Put the test subject first, the test statement next, and the expected result last.
That way, you get a clear indication of what it is doing, and you can easily sort by name :)

Answer 8

Yes, the whole point of the test name is that it tells you what doesn't work when the test fails.

Answer 9

[RowTest]
[Row("GoodName")]
[Row("GoodName2")]
public void Should_validate_username()
{
}

[RowTest]
[Row("BadUserName")]
[Row("Bad%!Name")]
public void Should_invalidate_username()
{
}

This might make more sense for more complex types of validation really.

Answer 10

Yes, they are. I'd personally recommend looking at SSW's rules to better unit tests. It contains some very helpful naming guidelines.

Answer 11

Yes, the names are totally important, specially when you are running the tests in console or continuous integration servers. Jay Fields wrote a post about it.

Moreover, put good test names with one assertion per test and your suite will give you great reports when a test fails.

Kind Regards

Answer 12

Having a very descriptive name helps to instantly see what is not working correctly, so that you don't actually need to look at the unit test code. Also, a list of all the unit tests describes the intended behavior of the unit, and can be used (more or less) as documentation to the behavior of the unit under test.

Note, this only works when unit tests are very specific and do not validate too much within one unit test.

So for example:

[Test]
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100()

[Test]
void TestThatStringLengthOf99IsAccepted()

Answer 13

In Clean Code, page 124, Robert C. Martin writes:

The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.