Hey Stephane, In the past I've used a JOOQ/Flyway combo, with Flyway to create the DDL in HSQL and populate it and then run the JOOQ generator against this instance to generate your record definitions. Both work with Maven, should you be using that.
I think the issue you will run into is the ropeyness of schema management tools when you compare them to JOOQ's slickness. Unfortunately there doesn't seem to be many DDL tools that are designed well enough to cope with arbitrary requirements and workflows other than having to roll your own DDL patch management solution. To be fair to the tools that do try to solve these issues, I think portable DML is more tractable than portable DDL. HTH, Ben On Wed, May 8, 2013 at 9:57 AM, Stéphane Cl <[email protected]> wrote: > Hello, > I would be interested to know what strategies people are using for testing > their application. > > I have started writing a prototype application and now that the > requirements are more or less stable, I d'like to implement a testing > strategy. > Previous experiences suggest that testing against a database would be the > least pain. I know it's common practice to use DI and a mocking framework > to simulate different scenarios but in my particular case, it seems that > writing high level integration tests against a sample database would have > better chances of detecting problems for more or less the same amount of > work, mostly because they will go though every layer. > > However I am not sure how I should manage the sample data. I can think of > the following : > > 1) Manually pre-populate a sample database with interesting cases of data. > Run Junit tests directly against the sample DB while abusing transactions > and rollbacks to leave the data unchanged. The sample DB creation script > would be under source control so that people can easily recreate the test > db and perhaps add new cases. > pro: may be less expensive than recreating DB and Data for every test, > reasonably easy to set up. > con: Db may go out of sync by accident, may interfere with in-app > transaction management > > 2) Maintain a sample database, use DBunit to extract datasets from it, > then have it restore some tables into a known state before every test. > pro: no risk of corrupting test data, reasonably fast as some tests may > not need a full copy of the database. > con: requires some work, need routines for generating its dataset files, > may make schema change slightly harder. > > 3) Use jooq record API to create the minimal amount of records in an empty > DB > pro : more isolation (especially if used with an in memory H2 DB with an > appropriate compatibility mode), easier schema change management > con : may need quite a lot of manual coding for inserting data > > Or perhaps something else, any advice or experience would be warmly > welcomed. > Regards > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
