On Tuesday, February 12, 2013 3:14:40 PM UTC+1, Lukas Eder wrote: I again fell into the trap of not explaining that I already spend several weeks of thinking about this and just posting the final results. Oh well ...
1. Write a simple JDBC mock layer. Your mock Connection / > PreparedStatements would look up mock ResultSets from a file > 2. Hook these JDBC mock objects into jOOQ's ExecuteListener lifecycle > MockRunner can do that. The last release (0.4.2) was 2009. The API is ... strange. To mock a ResultSet, you have to give the MockResultSet the values for each column as an array (i.e. it's not row based). Internally, it will then compile the arrays with column values into rows arrays. Actually, it takes a lot of work to prepare data in the form of a ResultSet (a class which has 187 methods and each of them has lots of intricate details). Writing a mock JDBC layer takes many, many lines of code and because of the broken API evolution in the VM, you will need a code generator step to build an instance per Java version. If I'd do the same with jOOQ, I'd just have to add a few times `public` to a few classes and methods and I'd just have to write a unit test compatible implementation of Record and intercept the one single point where a query is executed. Comparing the two, the first approach would take 100-500 times the effort of the second one. > Also, H2 has nice, text-based integration tests: > > http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/test-1.3.txt > > That just executes queries against a real (in-memory) database so I gain exactly nothing from this. It's not even related to my question, really. It's like the documentation based tests in Python docutils. > On the other hand, using an actual H2 (or Derby, HSQLDB) in-memory > database instance might be less work? > Less work? Absolutely. But in terms of test runtime, it would make a huge difference. Creating an H2 database takes a long time. Creating a list of object arrays, wrap them in a record and call a method that makes jOOQ return this wrapper form a certain SQL pattern is encountered would take only a few nanoseconds. It would also cut many dependencies from my tests (database drivers), make the test much more memory efficient, it would make it much, much easier to put "illegal" test data into the "database" because I wouldn't have to fulfill all the foreign key relations, etc. Regards, A. Digulla -- 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.
