db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Guidance on JDBC testing
Date Sun, 26 Apr 2009 12:01:34 GMT
Tiago Espinha <tiago@espinhas.net> writes:

> Hey everyone,
> I have just run in on a behavior and I would like an opinion on the best way
> to solve it.
> The deal is, I have a JDBC test that uses both client/server and embedded
> drivers; however, on one of the fixtures, the data on a table (that I am using
> decorateSQL to create) is changed. As a result, the embedded test runs fine,
> but when the client/server comes on, it errors out since the data on a table
> isn't as expected. I know this is the case because if I try to comment out
> either of the drivers, the other test runs fine.
> Now, given this scenario, what would be my best option? It seems that the
> decorateSQL is really just ran once for the whole test, suggesting that the
> tables don't really get dropped, not even between the different drivers.
> Should I delete all the data from the table on each fixture and insert it back
> on? Or is there a more orthodox way of approaching this issue?

Hi Tiago,

If the only thing you need is that the tables are dropped between the
different drivers, you could do a little refactoring to make sure that
decorateSQL() is run for each driver:

  private static Test decorateTest(Test test) {
    return new CleanDatabaseTestSetup(test) {
      protected void decorateSQL(Statement s) {

  public static Test suite() {
    TestSuite suite = new TestSuite();
    return suite;

Otherwise, using setUp() and tearDown() to do it for each fixture sounds
like the way to do it. For some tests it is also possible to turn off
auto-commit, and just let the changes be rolled back automatically when
the fixture has completed.

Knut Anders

View raw message