Posts Tagged ‘ Testing ’

OT2004 : Mock Objects: Driving Top-Down Development

Nat and I were first up with our talk on Mock Objects. Yes, we are still harping on about them :).

Here’s what we covered:

* OO concepts: an application is a web of collaborating objects, each providing a distinct responsibility and taking on multiple roles to provide services to other objects.
* How the process of using mock objects complements TDD to drive out the design of these responsibilities and roles.
* How our original usage of mocks for testing system boundaries such as databases, web-apps, GUIs, external libraries turned out to be a bad approach and the success we started achieving when inverting this to only mock types we can change.
* The process of using mocks very quickly points out key abstractions in your system, difference in responsibilities between objects and services objects require.
* Clearing up misconceptions about mocks, including: not using them at system boundaries and what they actually are (not stubs, not recorders, no behaviour).
* Our first public demonstration of the new JMock API to walk through a single iteration of the process.
* Usage patterns.

Feedback from: James Robertson @ Cincom Smalltalk and Mike Platt @ Microsoft.

Making JUnit friendlier to AgileDox

Here’s a little trick to make JUnit display your test results in a similar way to AgileDox.

Override TestCase.getName() in your unit test…

public String getName() {
return super.getName().substring(4).replaceAll("([A-Z])", " $1").toLowerCase();
}

… and your test runner results are transformed from this …

… to this …

To make this easier, stick it in an abstract TestCase and inherit from that instead.

Tutorial: Using mock objects to drive top-down development

Tim Mackinnon and Nat Pryce and Steve Freeman and I are presenting a session on how mock objects can be used to drive code from the top (requirements first, infrastructure last) to produce high quality, clean and decoupled object designs that allow for business change.

Come see us at:
* XPDay Benelux – Fri 21st Nov 2003, Breda, Netherlands
* XPDay London – Tue 2nd Dec 2003, London, UK.
* OT2004 – Tue 30 Mar 2004, Cambridge, UK.

Excerpt:

Mock objects are usually regarded as a programming technique that merely supports existing methods of unit testing. But this does not exploit the full potential of mock objects. Fundamentally, mock objects enable an iterative, top-down development process that drives the creation of well designed object-oriented software.

This tutorial will demonstrate the mock object development process in action. We will show how using mock objects to guide your design results in a more effective form of test driven development and more flexible code; how mock objects allow you to concentrate more on end-user requirements than on infrastructure; and how the objects in the resultant code are small and oosely coupled, with well-defined responsibilities.

Includes:
* Brief introduction to mock objects and the dynamic mock API.
* The mock object design process explained.
* Top down vs. bottom up design.
* What to mock. And what not.

More…

Test Driven Development is not about testing

Dan writes:

bq. “Writing the test before you write the code focuses the mind – and the development process – on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests. ”

Read the rest here.

Design by contract: testing implementations of interfaces

Here’s a nice way of associating contracts with interfaces and testing the implementations conform.

A sample interface:

interface CheeseMaker {
int getCheeseCount();
void addCheese(Cheese cheese);
}

With the contracts:

* there should be zero cheeses on creation.
* adding a cheese should increment the count.
* unless the cheese is a duplicate.
* when adding a cheese, the cheese cannot be null.

You can create an abstract unit test for this interface that tests these contracts. The only thing it doesn’t do is provide an implementation – instead it has an abstract factory method.

public abstract class CheeseMakerTest extends TestCase {

// abstract factory method
protected abstract CheeseMaker createCheeseMaker();

public void testZeroCheesesOnCreation() {
CheeseMaker cheeseMaker = createCheeseMaker();
assertEquals(0, cheeseMaker.getCheeseCount());
}

public void testAddingACheeseIncrementsCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Wensleydale"));
assertEquals(2, cheeseMaker.getCheeseCount());
}

public void testDuplicateCheesesDoNotIncrementCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Cheddar"));
assertEquals(1, cheeseMaker.getCheeseCount());
}

public void testNullCheeseCausesIllegalArgumentException() {
CheeseMaker cheeseMaker = createCheeseMaker();
try {
cheeseMaker.addCheese(null);
fail("expected exception");
} catch (IllegalArgumentException e) {} // good
}

}

Now, every time you create an implementation of CheeseMaker, the test should extend CheeseMakerTest and you inherit the contract tests for free.

For example:

public class BigCheeseMaker implements CheeseMaker {
// ... ommited for sanity
}

public class BigCheeseMakerTest extends CheeseMakerTest {

// factory method implementation
protected CheeseMaker createCheeseMaker() {
return new BigCheeseMaker();
}

// ... any additional tests go here

}

It’s important to note that this tests the contract but does not enforce them. It’s very flexible and there are very few contracts (if any at all) that couldn’t be expressed in a unit-test.

This helps defensive development with the added safety of unit-tests.

As a bonus, you can use TestDox to generate documentation for interfaces (much more useful than implementations), like so:

h4. CheeseMaker

* Zero cheeses on creation.
* Adding a cheese increments count.
* Duplicate cheeses do not increment count.
* Null cheese causes illegal argument exception.

Agiledox

Chris Stevenson, fellow team-member, has started Agiledox, a small project to collect ideas and tools for automating documentation.

It is typical in agile projects that the code and design changes so quickly that the documentation (if any) never keeps up. We are using Agiledox on our current project to help give us all a high-level map of what the system does at all times.

When practicing *collective code ownership* it is vital that all developers know how the entire system works, not just _their_ bit (they have no bit). With bigger systems that are constantly evolving it is unlikely that any one person knows how it all works, so it’s nice to have a higher level roadmap of the system to look around before drilling into some code. Of course, this is no substitute for good communication – but it helps.

The first deliverabe in Agiledox is Testdox . It autogenerates documentation from testcases. Wow! How?

Simple. All it does is look at a test class and all the test method names and convert them from camal case Java names to sentences. Genius!

You may laugh, as I did. But I was amazed at what it produced for our project.

There’s a catch though. It worked for us because we are well disciplined in the way we write tests. For a start, we were already in the habit of writing test case method names that describe what a class should _do_ rather than what all the methods are. Don’t moan that this low emission petrol isn’t great when you’re trying to put it in a deisel engine.

Run Testdox through WebStart.

Here’s a handful of docs generated for our project. Sweet huh?

h3. MenuModel

* View can be bound to a model
* Two views can be bound to one model
* Model contains menu text
* Model contains menu text after it is renamed
* View is populated from prepopulated model
* Model can be cleared
* Model can contain separator

h3. CsvTableModel

* Column definitions are read from first row
* Values can be read from rows
* Column definition values return underlying value
* Model can be reloaded
* Column can be marked as date

h3. NewOrderFinder

* Order with fills are returned
* Old orders and old fills are filtered out
* Old orders with new fills are not filtered out
* Assumed legs are filtered out
* Last check is maintained
* Spread components are grouped together

MockObjects Java 0.09

The latest release of the Mock Objects Java project is available. The dynamic mock generation API has been improved greatly and it now allows a lot more flexibility in setting up expectations and return values resulting in less brittle tests.

“Website”:http://www.mockobjects.com/
“Download”:http://sourceforge.net/projects/mockobjects/

NMock 1.0

After many months of little changes, we deemed NMock production quality. It stabilised quickly many months ago and has changed very little since.

Documentation is somewhat sparse – contributions welcome!

http://nmock.truemesh.com/”:http://nmock.truemesh.com/