Hi Adam, > I sort of stumbled on this thread a little late but is the issue that you > (digulla) can't assert the SQL that is generated by jOOQ?
Hmm, yes, looks like you're a bit late ;-) The latest suggestion by Aaron here was to find a way that String s = record.toString(); Record other = someParseMethod(s); record.equals(other); // More or less His idea here was that actual test data for this new MockFileDatabase could be dumped from sample queries with jOOQ's DEBUG logger. The logger would then produce both a relevant SQL statement, and the result in a similar way that I had originally suggested (H2 test format, as can be seen here: http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/test-1.3.txt) > It sounds like what your looking for an abstraction above JDBC to mock. I > did this for my library: > https://github.com/agentgt/jirm/tree/master/jirm-core/src/main/java/co/jirm/core/execute Mocking jOOQ's API in this way would probably be worse than mocking JDBC, as the API evolves quickly, and there are already hundreds of methods in various org.jooq.* types. Aaron's original idea was to be able to "inject" results to jOOQ's internals, preventing actual execution. > However I think the spirit of jOOQ is to embrace JDBC so JDBC is exposed > much more all over. > Thus I think Lukas's Mocking JDBC contributions should be a good starting > point. Yes. JDBC is the right place to inject mock data, as it has the least impact on jOOQ's delicate internals > Of course I think your insane for mocking JDBC when you can just execute to > a real database... but I too used to drink the mocking cool-aid :) Well, if the mocking is done for you transparently, in a library, then you're not mad anymore (except me for actually doing it). But I share your feelings about the "real database". There are lots of advantages in running nightly integration tests, when it comes to large-scale testing. It is extremely hard to mock things like: - Concurrent transactions - Pessimistic locking - "advanced" CRUD (i.e. modifying more than one table in a semantically correct sequence) - etc. Anyway, it's good that the user can choose, now. There are 1-2 use-cases for real unit tests that don't run against a DB Cheers Lukas > On Monday, February 18, 2013 7:51:07 AM UTC-5, digulla wrote: >> >> On Monday, February 18, 2013 11:52:43 AM UTC+1, Lukas Eder wrote: >> >>> > Not right now. I'll first see how this is adopted. Feel free to >>> > suggest / contribute one >>> >>> Note that I'm going to implement a file-based API soon, as I think >>> that is easier to handle for end users: >>> https://github.com/jOOQ/jOOQ/issues/2208 >>> >>> A draft implementation is already included in 3.0-RC1 >> >> >> How about a parser that can read the output of Record.toString()? That >> would make it dead simple to produce the test data (just run the query once >> against a real database). >> >> 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. > > -- 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.
