• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Mock DB

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have found it beneficial for test-driven development to build a persistence layer that can be targeted for an in-memory data store. Persistence calls are directed to a list of lists of objects, one list per persistent entity. This is essentially a mock DB. Testing is done continuously against a fast local memory data store. Periodically, testing is done against the true DB by setting a service initialization parameter in a startup XML configuration file.
There are several caveats to this approach, e.g. implementing a transient cascade delete and referential integrity. It is a challenge to balance the implementation effort vs. coverage. Nevertheless, it has proven worthwhile.
Is there a good open-source framework for such a mock DB persistence layer? With the routine advice to build a persistence layer, why is a mock DB persistence service apparently considered a novelty?
There is one significant drawback to continuous development with a mock DB: clients of the persistence service assume that what works with an isolated memory DB will automatically obtain with a shared remote DB. This is one manifestation of a bigger XP problem: postponing a target implementation engenders a false client expectation based on the provisional implementation. Is there a way to avoid this besides stipulating "Don't assume what won't be true", a caution that is routinely ignored in the heat of development?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Testing is done continuously against a fast local memory data store. Periodically, testing is done against the true DB by setting a service initialization parameter in a startup XML configuration file.


How about using mock objects for testing your units and testing against a real database by creating a known data setup using dbUnit?

There is one significant drawback to continuous development with a mock DB: clients of the persistence service assume that what works with an isolated memory DB will automatically obtain with a shared remote DB.

I didn't quite get what you mean here?

This is one manifestation of a bigger XP problem: postponing a target implementation engenders a false client expectation based on the provisional implementation.

By false expectations, do you mean that performance drops once you move to a persistent database?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are talking about unit testing, I don't fully understand how your "Mock DB" works. Can you give a simple example?
When speaking about Acceptance Testing, I'd advice to try a real in-memory database, like HSQL.
 
FredLoney
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

How about using mock objects for testing your units and testing against a real database by creating a known data setup using dbUnit?


That is the process: mock objects for routine unit testing, and a real database for real database unit testing. dbUnit facilitates real database unit testing by restoring the db to a known state.

By false expectations, do you mean that performance drops once you move to a persistent database?


That along with every other difference between memory and persistent db: network latency, transaction integrity, db failure, scalability, et al.
The functional differences are often the more dangerous to ignore. The worst assumption is that all data is instantly available for long-term isolated edits. It is easy for a developer accustomed to working against memory objects to forget that persistence yields different behavior -- and slower response is the least of these differences.
A mock persistence object assumes a persistence protocol, e.g. application objects with CRUD and query methods. That is the target layer, not the SQL calls. Hence, HyperSQL by itself is not enough. The real drag on development is the J2EE weight around the db. Unit testing model logic locally outside of a J2EE container against mock persistence objects is a lot faster than testing against J2EE + HyperSQL. Of course, view logic still must be tested in the container.
[ January 19, 2004: Message edited by: Fred Loney ]
 
These are not the droids you are looking for. Perhaps I can interest you in a tiny ad?
Enterprise-grade Excel API for Java
https://products.aspose.com/cells/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!