Comments on: Isolating database data in integration tests

By: Isolating the Database When Testing | Chuck Conway

Isolating the Database When Testing | Chuck Conway — Fri, 10 May 2013 07:25:56 +0000

[...] Bogard wrote a post about Isolating the database when testing. I highly recommend reading [...]

By: Name of the blog | Using a "data builder" class for isolating database data in individual tests

Sat, 06 Apr 2013 11:47:00 +0000

[...] in individual tests by boniestlawyer 23. November 2012 11:40 This post is mostly a reply to this (http://lostechies.com/jimmybogard/2012/10/18/isolating-database-data-in-integration-tests/) post by Jimmy Bogard. How my company has managed the test databases for [...]

By: jbogard

jbogard — Mon, 19 Nov 2012 20:24:00 +0000

What’s slow about it?

By: roberto.delloglio

roberto.delloglio — Sun, 18 Nov 2012 21:07:00 +0000

I’m using the rebuild database from scratch before the tests start and then the delete all approach. But is more interesting to understand what is the strategy to setup the fixture. I’m currently using the same API of the system in order to put the database in the right state and than performe the action. I’ve found this way the best one for maintenance purpose (is not dependent on the database schema and is easily refactorable) but I’ve find it sometimes slow. What’s your preferred way?

By: Guest

Guest — Sun, 18 Nov 2012 20:58:00 +0000

By: gorlok

gorlok — Mon, 05 Nov 2012 13:10:00 +0000

I prefer in-memory db. It works most of the time. Store procedures are an exception: SP are tested in a real (shared) test-database.

By: Richard Wilde

Richard Wilde — Thu, 01 Nov 2012 20:08:00 +0000

Good point it makes sense, in dev land schema’s are constantly changing

By: jbogard

jbogard — Thu, 01 Nov 2012 20:06:00 +0000

Not if the schema was changing. And it also depends on the # of tables, we’ve found. We had to play with several different ways of doing this to find the right fit for the schema we were working with.

By: Richard Wilde

Richard Wilde — Thu, 01 Nov 2012 20:03:00 +0000

Instead of deleting tables, why not restore the whole database to a known state? Would this not be quicker?

By: Bill Turner

Bill Turner — Wed, 31 Oct 2012 18:00:00 +0000

So why not HSQLDB (or equivalent), DbUnit, Unitils and, if appropriate, spring-test-dbunit? You CI server should have it’s own DB, the same version as PROD. Using an in-memory db solves a lot of pain.