I have difficulty in many situations to come up with a good unit test names for classes and methods. Typically, I try to follow the form:
public class TestContext
{
[Fact]
public void WhenThis_DoThat()
{
}
}
Some put words Given, When, and Then on the parts to be explicit. I like it because it seems to make the unit test clearer on what it is that it's testing. Aside from considering BDD toolkits, I need some advice in how this can work with plain old xUnit tools.
I'm having especially hard time with scenarios like this:
When Application starts up, the main form loads and user sees a list of links which the user can click on.
or maybe a better use case scenario is:
User can select a link from a list of links.
I'm not certain but I'm trying to describe a behavior where you run an app and the form loads with a list of clickable links. And turning that into a unit test.
What is the Given, When, and Then for that?
Here is how I write tests in BDD specification style: http://github.com/orfjackal/tdd-tetris-tutorial
What is needed, is the ability to have multiple test fixtures in one class. Then it's possible to organize the tests so, that each fixture is the "Given/When" part and each test method is the "Then" part. JUnit does not support it, so I wrote a simple test runner for it:
@RunWith(NestedJUnit4.class)
public class WerewolfTest extends Assert {
public class Given_the_moon_is_full {
@Before public void When_you_walk_in_the_woods() {
...
}
@Test public void Then_you_can_hear_werewolves_howling() {
...
}
@Test public void Then_you_wish_you_had_a_silver_bullet() {
...
}
}
public class Given_the_moon_is_not_full {
@Before public void When_you_walk_in_the_woods() {
...
}
@Test public void Then_you_do_not_hear_any_werewolves() {
...
}
@Test public void Then_you_are_not_afraid() {
...
}
}
}
I'm quoting Introducing BDD from Dan North:
Test method names should be sentences
My first "Aha!" moment occurred as I was being shown a deceptively simple utility called agiledox, written by my colleague, Chris Stevenson. It takes a JUnit test class and prints out the method names as plain sentences, so a test case that looks like this:
public class CustomerLookupTest extends TestCase { testFindsCustomerById() { ... } testFailsForDuplicateCustomers() { ... } ... }
renders something like this:
CustomerLookup – finds customer by id – fails for duplicate customers – ...
The word "test" is stripped from both the class name and the method names, and the camel-case method name is converted into regular text. That’s all it does, but its effect is amazing.
Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.
The whole paper is actually worth the read. Warmly recommended!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With