Hi Stéphane, After an interesting request on this user group by Aaron Digulla: https://groups.google.com/d/msg/jooq-user/OQzuxbqk-w8/MbtmKAnZ2h4J
I have implemented a mock database to suit his needs, which are the actual mocking of the database (instead of integration testing). I then wrote an article which was reblogged to DZone and lead to heated, yet interesting discussions: http://blog.jooq.org/2013/02/20/easy-mocking-of-your-database http://architects.dzone.com/articles/easy-mocking-your-database-0 While I don't think that there is a definitive answer to your question, short of "it depends", I'm personally much in favour of integration tests. The main reason is the famous 80/20 rule. You get 80% of coverage with 20% of the effort, because of the reasons you stated, you get free coverage of all the other layers as well. The aforementioned MockDatabase is useful in very limited use-cases only, in my opinion. I mainly implemented it 1. For the fun of the task. 2. For marketing purposes. I get many search hits because of people looking for database testing ;-) The "it depends" part is caused by your general architecture. If you're using H2 anyway, or if you can reasonably emulate your productive system with H2, you might be able to create a binary copy of a reasonably simple database and drop/recreate the database after every writing test (i.e. test with side-effects in the database). Obviously, you'll also write a significant amount of read-only tests, which do not affect the data. If, however, you have a huge Oracle schema, re-creating the test data is costly. So... it really depends :-) I will soon blog about this topic. Curious to hear more feedback on this thread. Cheers Lukas 2013/5/8 Stéphane Cl <[email protected]> > 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.
