"A trick I have used several times is to make an InMemoryImpostor for the database. I have some tests that make sure that the lowest layer of database access works as planned. That has to really use a database, but (I hope) it is a small suite because we don't have a million ways of interacting with the database (if we do have a million ways, we fix the design so we no longer have a million ways).

Then I write a suite based on the assumptions demonstrated by the first suite. It assumes that I can get things into and out of the real database, so I don't have to have the real database there. That way I can create an in-memory imposter for the database and exercise the higher level objects. 

The latter suite runs very quickly and is very stable. The former suite is relatively slow and it breaks all the time (because servers move around, the schema changes, etc.)" -- KentBeck
-----
In hardware design circles this is known as a '''shunt'''. A Shunt is basically a wire that goes out the back of one jack, and into an input, so the machine is connected to itself. Then you run the machine, and it thinks it is connected to the world, but it is only talking to itself.

In software, the trick is to fake communication against the outside world, then run the tests locally. Then your testing is partitioned, as Kent describes.

Probably worth a pattern description, because it is well known in hardware design circles and rarely seen in software. I am always stunned by its absence. On one project, with sharp people designing the persistence framework, they had never thought about making a Shunt. So whenever they changed their framework, all the rest of us suffered for days. I asked if they couldn't make a system like Kent described, and they said it would be too hard to add in at that point. See also SoftwareDesignForTesting. -- AlistairCockburn

This has been patternized at ShuntPattern.
----
I HaveThisPattern too. Once on a distributed system, I made and registered imposters for services. I created a NullObject for the abstract interface of the service so that I could instantiate it. Then I made trivial subclasses of the NullObject, often on a per TestCase basis, to fill in the behavior expected during the test, log the invocations, and set conditions that can be checked during the test. -- MichaelFeathers

''I have done almost exactly the same too for a system which had various services it relied upon. I implemented fake services and asserted that those services had been used in the expected way. Cool, it wasn't a mad idea :-) -- ChanningWalton ''
----
This is another one that I can't believe hasn't been patternized already. It's basic to testing LayeredSystems. In the presentation I give to customers about FourLayerArchitecture I mention that the strategy to follow is to build your domain classes first (ModelFirst) and then test it in place - of course, to do this you need shunts for the database and other infrastructure classes.

-- KyleBrown

BTW, after getting frustrated that NO-ONE would patternize this, I finally wrote an article about it where I tied it into the DAO pattern from John Crupi's Core J2EE Patterns: 
* www-106.ibm.com/developerworks/java/library/j-sdao/  ( BrokenLink )


Try instead:
*** http://www.ibm.com/developerworks/rational/library/nov04/naiburg-maksimchuk/UMLChap4excerpt.pdf
-----

See also MockObject

----
CategoryTesting CategoryMockObjects