Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

TDD: Consistent test structure

03.24.2010
| 4838 views |
  • submit to reddit

While pairing with Damian we came across the fairly common situation where we'd written two different tests – one to handle the positive case and one the negative case.

While tidying up the tests after we'd got them passing we noticed that the test structure wasn't exactly the same. The two tests looked a bit like this:

[Test]
public void ShouldSetSomethingIfWeHaveAFoo()
{
var aFoo = FooBuilder.Build.WithBar("bar").WithBaz("baz").AFoo();

// some random setup
// some stubs/expectations

var result = new Controller(...).Submit(aFoo);

Assert.That(result.HasFoo, Is.True);
}
[Test]
public void ShouldNotSetSomethingIfWeDoNotHaveAFoo()
{
// some random setup
// some stubs/expectations

var result = new Controller(...).Submit(null);

Assert.That(result.HasFoo, Is.False);
}

There isn't a great deal of difference between these two bits of code but the structure of the test isn't the same because I inlined the 'aFoo' variable in the second test.

Damian pointed out that if we were just glancing at the tests in the future it would be much easier for us if the structure was exactly the same. This would mean that we would immediately be able to identify what the test was supposed to be doing and why.

In this contrived example we would just need to pull out the 'null' into a descriptive variable:

[Test]
public void ShouldNotSetSomethingIfWeDoNotHaveAFoo()
{
var noFoo = null;

// some random setup
// some stubs/expectations

var result = new Controller(...).Submit(noFoo);

Assert.That(result.HasFoo, Is.False);
}

Although this is a simple example I've been trying to follow this guideline wherever possible and my tests now tend to have the following structure:

[Test]
public void ShouldShowTheStructureOfMarksTests()
{
// The test data that's important for the test

// Less important test data

// Expectation/Stub setup

// Call to object under test

// Assertions
}

As a neat side effect I've also noticed that it seems to be easier to spot duplication that we can possibly extract with this approach as well.

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Csala replied on Wed, 2010/03/24 - 7:57am

This is basically the usual Given-When-Then structure well known in BDD. Such as: Given some initial context (the givens), When an event occurs, then ensure some outcomes. (as it can be found here: http://blog.dannorth.net/introducing-bdd/ )

Daniel Marbach replied on Wed, 2010/03/24 - 4:01pm

Hy,

 Arrange, Act and Assert. As simple as it is ;)

 Daniel

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.