db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: Guidance on JDBC testing
Date Sun, 26 Apr 2009 13:21:56 GMT
Hello Knut,
Thank you very much for your suggestion :)

I went for the refactoring because all in all, I think that's the best
option for this test in specific. At this point I am using a separate table
for each fixture since there are several different ones (and some fixtures
require data in the tables, some don't, etc), and I am creating them all on
the decorateSQL. Using the setUp() and tearDown() methods would be a little
more complicated since literally each fixture has its own table.

I just tested what you suggested and it works perfectly so I am sticking to
it.

Thanks again!
Tiago

On Sun, Apr 26, 2009 at 1:01 PM, Knut Anders Hatlen <Knut.Hatlen@sun.com>wrote:

> 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();
>    suite.addTest(decorateTest(
>       TestConfiguration.embeddedSuite(MyTest.class)));
>    suite.addTest(decorateTest(
>       TestConfiguration.clientServerSuite(MyTest.class)));
>    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
>

Mime
View raw message