Unit test naming best practices

What are the best practices for naming unit test classes and test methods?

This was discussed on SO before, at What are some popular naming conventions for Unit Tests?

I don't know if this is a very good approach, but currently in my testing projects, I have one-to-one mappings between each production class and a test class, eg Product and ProductTest .

In my test classes I then have methods with the names of the methods I am testing, an underscore, and then the situation and what I expect to happen, eg Save_ShouldThrowExceptionWithNullName() .

---

I like Roy Osherove's naming strategy, it's the following:

[UnitOfWork__StateUnderTest__ExpectedBehavior]

It has every information needed on the method name and in a structured manner.

The unit of work can be as small as a single method, a class or as large as multiple classes. It should represent all the things that are to be tested in this test case and are under control.

For assemblies I use the typical .Tests ending, which I think is quite widespread and the same for classes (ending with Tests ):

[NameOfTheClassUnderTestTests]

Previously I used Fixture as suffix instead of Tests but I think the latter is more common, then I changed the naming strategy.

---

I like to follow the "Should" naming standard for tests while naming the test fixture after the unit under test (ie the class).

To illustrate (using C# and NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Why "Should" ?

I find that it forces the test writers to name the test with a sentence along the lines of "Should [be in some state] [after/before/when] [action takes place]"

Yes, writing "Should" everywhere does get a bit repetitive, but as I said it forces writers to think in the correct way (so can be good for novices). Plus it generally results in a readable English test name.

Update:

I've noticed that Jimmy Bogard is also a fan of 'should' and even has a unit test library called Should .

Update (4 years later...)

For those interested, my approach to naming tests has evolved over the years. One of the issues with the Should pattern I describe above as its not easy to know at a glance which method is under test. For OOP I think it makes more sense to start the test name with the method under test. For a well designed class this should result in readable test method names. I now use a format similar to <method>_Should<expected>_When<condition> . Obviously depending on the context you may want to substitute the Should/When verbs for something more appropriate. Example: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

---

I like this naming style:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

and so on. It makes really clear to a non-tester what the problem is.

链接地址: http://www.djcxy.com/p/21402.html

上一篇: 你如何测试私有方法？

下一篇: 单元测试命名最佳实践