On Friday, February 15, 2013 2:37:28 PM UTC+1, Lukas Eder wrote: So when using jOOQ, you only have to "support" JDBC 4.0 >
This code would only compile with Java 6. Java 5 would complain about methods with @Override that don't exist in the interface and Java 7 would complain about unimplemented methods. I'm not sure what happens when you try to run this on Java 7. Do you get a MethodNotImplementedException at runtime? > Yes, but with Java 8, extension methods are in place. Check out Statement: > > http://hg.openjdk.java.net/lambda/lambda/jdk/file/ee1fce80ec31/src/share/classes/java/sql/Statement.java > > > It contains: > > 1091 default long getLargeUpdateCount() throws SQLException { > 1092 throw new > UnsupportedOperationException("getLargeUpdateCount not implemented"); > 1093 } > > Beautiful, eh? :-) > :-P > > Just look at > org.jooq.impl.FieldTypeHelper.getFromResultSet(ExecuteContext, > > Class<? extends T>, int) to get an idea how much of the ResultSet API > I'd > > have to replicate. > > Here's another suggestion: Since I... > > - really don't want to give any guarantee about jOOQ's internals to you > - understand your use-case interface MockDataProvider { ... } Example. I have this code in my DAO: UserRecord row = jooq.create() .selectFrom( ADM_USER ) .where( ADM_USER.ADM_USER_ID.equal( pk ) ) .fetchOne() ; To write a test for this, I need to create 8 tables and fill them with data because of foreign key relations. What I'd like: UserRecord testData = new UserRecord(): ... set fields ... factory = new JooqTestSetup(dialect, settings) .query( "select A, LOT, OF, COLUMNS from ADM_USER where ADM_USER.ADM_USER_ID = 1" ) .shouldReturn( testData ); query() takes the SQL string that you get from factory.renderInline() 1:1 (i.e. when I have formatting enabled, I need to pass the multi-line string) Or there could be query(string, Object[] bindValues) and queryInline(). shouldReturn() takes one or more Record types to make it easier to write correct test data. If it should return no results, I'd like returnsNothing(). I could live with the Object[][] solution as well but it will make tests more brittle/less readable. If you use record types, you get all the advantages of the existing API (type safety, compile errors when the DB schema changes, ...) And you can use test data factories to quickly many records. We could even wire them correctly to the factory by using the newRecord() method of the returned test factor. I think queries are most important. But UPDATE/INSERT should be simple to add. I'm just not sure what the method names would be. An additional feature would be throwsException(SQLException) to support testing error handling. I could implement MockConnection, MockStatement, etc. Okay, have fun :-) > > And even when I could mock Cursor.fetch(), ResultImpl is package private > so > > I'd have to cut&paste these 1931 lines to implement Result unless > putting my > > code into org.jooq.impl which I don't like. > > Well, jOOQ would hardly evolve if I didn't keep the impl parts package > private. Every release would be a major release, then... > I don't doubt that. But I'm also 95% sure that doing what I want is much less effort by hiding it inside of jOOQ than by mocking JDBC. I don't know all the details how to do it and what the best solution would be and what parts of the API you can change, etc. But I'm sure this would be a great feature that will make testing DB related code more simple, more stable and much cheater to maintain than any other, existing approach. People just never tried that because there was no abstraction layer between their code and JDBC. But when I had to write code using JDBC, I always used classes where the JDBC code was hidden in a few methods that I could easily overwrite from tests. That way, I ended up with 5% JDBC tests (making sure the few JDBC methods do work) and 95% of the tests that don't notice when JDBC isn't there. 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.
