Comments on: TDD: Combining the when and then steps

By: Mark Needham

Mark Needham — Tue, 17 Nov 2009 14:12:19 +0000

That seems fine to me – it’s still possible to understand what’s going on in the test just from reading it and you haven’t pulled out too much of the test into other methods.

By: Josh Ribakoff

Josh Ribakoff — Mon, 16 Nov 2009 12:18:43 +0000

Take for example

[code]
function testListAll()
{
$this->createMMY();
$test1_id = $this->insertModel( $this->make_id, 'Y' );
$test2_id = $this->insertModel( $this->make_id, 'Z' );
$model = $this->findModelById( $this->model_id );
$expected = array();
$expected[0] = $this->findModelById( $this->model_id );
$expected[1] = $this->findModelById( $test1_id );
$expected[2] = $this->findModelById( $test2_id );
$this->assertEquals( $expected, $model->listAll(), 'should return exactly the right items, in alphabetical order, and nothing more' );
}
[/code]

Becomes…

[code]
function testListAll()
{
// fixture
list( $inserted_id1, $inserted_id2 ) = $this->createMMYWithAddtModels();
// SUT
$model = $this->findModelById( $this->model_id );
// verify!
$expected = $this->getEntities( $this->model_id, $inserted_id1, $inserted_id2 );
$this->assertEquals( $expected, $model->listAll(), 'should return exactly the right items, in alphabetical order, and nothing more' );
}
[/code]

By: Josh Ribakoff

Josh Ribakoff — Mon, 16 Nov 2009 12:08:41 +0000

You should also factor out duplication into creation methods that accept as parameters, values that are relevant to the outcome of that particular test.

By: Josh Ribakoff

Josh Ribakoff — Mon, 16 Nov 2009 12:02:08 +0000

I disagree with you, test code duplication is bad and causes all the same problems it causes in production, however unlike production code it is not as high of a priority, there is a higher priority which is tests as documentation (which is why it should have been moved in your example).

If you are duplicating data that does not affect the outcome of the test, then you move it out of the test method so we say to the reader “the value you do not see do not affect the outcome values” – XUnit Testing Patterns

By: Reflective Perspective - Chris Alcock » The Morning Brew #477

Reflective Perspective - Chris Alcock » The Morning Brew #477 — Mon, 16 Nov 2009 08:44:40 +0000

[...] TDD: Combining the when and then steps – Mark Needham talks about how a strict adherence to the DRY (Don’t repeat yourself) Principle in Unit Tests can result in less readable tests. Mark also issues A reminder to talk to the rubber duck, a useful technique which I refer to as the ‘Code Bear’, where simply expressing the problem you are having leads to a solution [...]

By: Daniel Marbach

Daniel Marbach — Sat, 14 Nov 2009 15:25:26 +0000

I would prefer the following structure:

@Test
public void WhenOriginalValueAndNewValueAreEqualCalculatedPercentageMustBeZero() {
const int originalValue = 100;
const int newValue = 100;
const int expectedPercentageDifference = 0;

PercentageCalculator testee = this.createTestee();

assertEquals(expectedPercentageDifference ,testee.calculatePercentage(originalValue, newValue)
}

@Test
public void WhenOriginalValueIsHalfOfNewValueCalculatedPercentageMustBeOneHundred() {
const int originalValue = 50;
const int newValue = 100;
const int expectedPercentageDifference = 100;

PercentageCalculator testee = this.createTestee();

assertEquals(expectedPercentageDifference ,testee.calculatePercentage(originalValue, newValue)
}

and so one…

private PercentageCalculator createTestee() {
return new PercentageCalculator();
}

By: Bryan Cook

Bryan Cook — Fri, 13 Nov 2009 14:39:17 +0000

I had the exact same argument with a developer the other day. Concise, elegant tests are great, but there comes a point where abstracting away test details limits our ability to understand the structure of the code itself.