-
Thanks for agreeing :-)
I was trying to reset the connection (ie. .setConnection(new MockConnection() ) in a @Before marked function. The unit tests we are running are transactional ( ie. AbstractTransactionalJUnit4SpringContextTests ) Therefore ( the problem ) spring grabs the connection to open a transaction before my '@Before' method.
Now of course I could use @DirtiesContext or a...
2009-07-07 14:29:26 UTC in Mockrunner
-
Sorry. that was added by me.
2009-07-07 13:15:46 UTC in Mockrunner
-
I've solved my problem. Turns out Spring isn't doing anything too fancy that mockrunner can't handle. Here are the details of "my mistake". I found that when my test class only had one test in it worked fine. Classes with multiple tests failed.
I discovered that that because of Spring injection, spring is holding onto the first MockDatasource I created either in a constructor...
2009-04-09 14:41:00 UTC in Mockrunner
-
I'm wondering if you had any sucess with this? I'm running into the same issue with a simular setup.
2009-04-09 13:44:06 UTC in Mockrunner
-
Ah, that's a good point. When one works with ORM so long that one forgets. From what I've read, JDK 1.4 implements the JDBC 3.0 standard which says it has named parameters for callable statements. I guess support is spotty.
Anyways... After more fiddling and testing I'm guessing that there is some incompatability between Spring JDBC and Mockrunner. As I remember the same is true for...
2009-04-09 12:37:11 UTC in Mockrunner
-
Maybe I just don't understand how this is supposed to work. I can't find any examples on using a Prepared statement with named parameters. Additionally we're using the Spring JDBC libs to help out which might be part of the problem.
I have not been able to find any examples on how to do this NOT VIA the prepareGlobalResultSet()
My Query is like "SELECT rndup_ind FROM...
2009-04-07 20:40:11 UTC in Mockrunner
-
AbstractParameterResultSetHandler redundantly defines some parameters that AbstractResultSetHandler has already defined. This is messing something up. If I remove the redundant parameters from AbstractParameterResultSetHandler and add calls to the proper parameter from the child it all works great.
Can I/We clean this up so there isn't any confusion?.
2009-04-07 18:18:27 UTC in Mockrunner