OK, finally found some time this afternoon to do some testing. I created a simple test project where I was JUST writing tests and you are correct that it works as you said... The problem, in the end, was that when I passed the DSLContext into my DAO. By assigning the passed DSLContext instance to the DAO's private instance I was actually creating a closure where the selector value would not change. So, I changed my test to create a new instance of the DAO after each selector value change and it works perfectly!!
AWESOME! That seriously simplifies my workflow for testing. I greatly appreciate the feedback! Deven On Wednesday, June 25, 2014 7:26:48 AM UTC-4, Lukas Eder wrote: > > Disregard that comment, which I copy-pasted from another test case: > > // Note: INSERT .. RETURNING is hard to mock for all dialects... > > > 2014-06-25 13:22 GMT+02:00 Lukas Eder <[email protected] <javascript:>>: > >> Hi Deven, >> >> I understand your use-case, now, but I strongly object putting something >> so test-implementation-specific into the library. Nothing keeps you from >> implementing whatever logic you need in your own MockDataProvider >> implementation: >> >> class MyLocalProvider implements MockDataProvider { >> int selector; >> >> @Override >> public MockResult[] execute(MockExecuteContext c) throws SQLException >> { >> DSLContext ctx = DSL.using(SQLDialect.POSTGRES); >> Field<Object> field = DSL.field("one"); >> >> Result<Record1<Object>> result = ctx.newResult(field); >> result.add(ctx.newRecord(field)); >> >> if (selector == 0) { >> result.get(0).setValue(field, 1); >> return new MockResult[] { new MockResult(1, result) }; >> } >> else { >> // Sneaky bug emulation >> result.get(0).setValue(field, 2); >> return new MockResult[] { new MockResult(0, result) }; >> } >> } >> } >> >> MyLocalProvider p = new MyLocalProvider(); >> >> // Note: INSERT .. RETURNING is hard to mock for all dialects... >> DSLContext ctx = DSL.using(new MockConnection(p), SQLDialect.POSTGRES); >> >> p.selector = 0; >> System.out.println(ctx.selectOne().fetch()); >> >> p.selector = 1; >> System.out.println(ctx.selectOne().fetch()); >> >> >> The above prints on the console: >> >> +----+ >> | one| >> +----+ >> | 1| >> +----+ >> >> +----+ >> | one| >> +----+ >> | 2| >> +----+ >> >> >> So, why change the library for this feature? >> >> 2014-06-25 12:39 GMT+02:00 Deven Phillips <[email protected] >> <javascript:>>: >> >> Let me elaborate on what I am trying to accomplish with the >>> MockDataProviders... Right now, the documentation explains that to retrieve >>> different result sets, you should implement logic which looks at the >>> generated SQL strings in order to choose which data to return. But, in my >>> use case, I might want to return several different result sets for the >>> exact same query so that I can test different branches of my DAOs, >>> mappings, ReST responses, etc... This means that in the current API, I have >>> to look at the bind variables in order to get different resultsets or I >>> would have to create multiple implementations of MockDataProvider and >>> MockConnection to cover my different branch requirements. Instead, it would >>> be much cleaner to have the ability to just tell the >>> MockConnection/MockDataProvider which resultset I want by having a >>> "selector" which could then be used instead of writing if/then/else >>> conditionals around the SQL string and bind variable values. I think that >>> the unit tests I submitted with the pull request demonstrate the use case >>> rather well.. >>> >>> Thanks, >>> >>> Deven >>> >>> On Wednesday, June 25, 2014 4:22:07 AM UTC-4, Lukas Eder wrote: >>> >>>> Hi Deven, >>>> >>>> I see you've been busy :) I'm trying to respond to all your mails in >>>> one. >>>> >>>> There's definitely room for improving the documentation around the >>>>> MockDataProvider... There are MANY cases where I would like to use the >>>>> bind >>>>> values to help determine the result sets and that is not documented >>>>> anywhere other than playing with the API. I will try to write up some >>>>> concise docs on using the bind values as well as the query matching to be >>>>> added. Other than that, I imagine it would be ideal to just somehow pass >>>>> an >>>>> identifier somehow so that you can explicitly choose a mock result for >>>>> each >>>>> query... I'm not sure what that would look like or how it could be >>>>> implemented; but I will think on it.. >>>> >>>> >>>> Yes, that's true. The MockDataProvider has been introduced as an >>>> experimental API at first with little documentation. It looks like the >>>> general direction is fine, but we haven't been working on it much any more. >>>> >>>> I'm curious about your bind variable use-case. Could you elaborate a >>>> bit more, perhaps? >>>> >>>> 2014-06-25 3:22 GMT+02:00 Deven Phillips <[email protected]>: >>>> >>>> Pull request cancelled and recreated after implementing unit tests and >>>>> more debugging. >>>>> >>>>> https://github.com/jOOQ/jOOQ/pull/3349 >>>>> >>>> >>>> I'll review that as soon as possible. >>>> >>>> Also, looks like the TravisCI builds are all passing and so it appears >>>>> there will be no regressions by incorporating these changes... >>>>> >>>>> Woot! >>>>> >>>> >>>> Congrats ;-) >>>> >>> -- >>> 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] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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/d/optout.
