How do we name test methods where we are checking for more than one condition?

Question

I follow the technique specified in Roy Osherove's The Art Of Unit Testing book while naming test methods - MethodName_Scenario_Expectation. It suits perfectly well for my 'unit' tests. But,for tests that I write in 'controller' or 'coordinator' class, there isn't necessarily a method which I want to test.

For these tests, I generate multiple conditions which make up one scenario and then I verify the expectation. For example, I may set some properties on different instances, generate an event and then verify that my expectation from controller/coordinator is being met. Now, my controller handles events using a private event handler. Here my scenario is that, I set some properties, say 3

condition1,condition2 and condition3

Also, my scenario includes

an event is raised

I don't have a method name as my event handler is private. How do I name such a test method?

Answer 1

If condition1,condition2 and condition3 is a business rule then name it after the rule.

Answer 2

I would use several tests and a different naming convention in this case:

• Name the test class ClassName_Scenario (so you would have more than one test class for the same class)
• Name the test methods Expectation1, Expectation2, Expectation3...

Also, instead of initializing the context in each test method, it would be initialized in a [SetUp] method

So you would have something like this:

[TestFixture]
public class ClassName_WhenScenarioX
{
     [SetUp]
     void InitContextForScenarioX()
     {
     }

     [Test]
     void ShouldDoY()
     {
         Assert.That(...)
     }

     [Test]
     void ShouldRaiseEventZ()
     {
         Assert.That(...)
     }
}

Note that this will only work if the order of execution of your asserts is not important (each test is independent, even if they all depend on the same initial context)

Answer 3

I tend to use almost full sentences to describe what the tested class should actually be providing. This way unit tests are almost a documentation of the class. I tend to avoid adding technical details to the name of the test though, because (1) these are in the content of the test anyway (2) someone might change the content of the test but not the name.

Examples:

[TestFixture]
public class ClassNameTests
{
     [SetUp]
     void BeforeEveryTest()
     {
     }

     [Test]
     void ParsesCsvStringsToLists()
     {
         Assert.That(...)
     }

     [Test]
     void ThrowsMyExceptionWhenInputStringIsMalformed()
     {
         Assert.That(...)
     }
}

Answer 4

I usually name my test methods after the scenario (and, if needed, its subcases), but I rarely include the method name or the expectations into the test name.

To me the scenario is most important, and this is what is not always obvious from the code, as it is on a higher level of abstraction than the code. So I need a nice descriptive test name to communicate it well. However, the called method is seen in the code, similarly the asserts / annotations document the expectations. And I am a big fan of the KISS principle...

I must add that I am working with legacy code, and our scenarios and unit tests typically are more bulky then a textbook unit test would be. Also, the interfaces we test are fairly simple, often having a single "execute" style of method per class.