Andrew, he is suggesting that he not mock the DB calls so the DB is actually modified and a transaction is used to wipe out the effects of the test. It’s a common method, especially if your CB logic is not easily separated.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Brad, yeah I sort of read that wrong. I guess when doing any unit tests I am a strong believer that the DB should rollback no mater what.
I agree Andrew. In fact, our current long-in-the-tooth model glue code is such that the tests don’t always clean up after themselves, which can leave pesky unit test records in the db. It’s one reason I’m very interested in doing something like this to ensure that whatever happens that it gets rolled back. Right now in my DAO object unit tests I have a transaction with a rollback in the finally so it does that; mostly I’m just looking for a way to make it DRY-er.
@Brad, I’ll look at the decorator and see if that will work for me. Thanks.
Ooh ooh ooh. It worked beautifully. The only thing is that if you insert some test setup data at the start of your test and it’s static and your test (as you’re developing it) maybe throws an exception that you didn’t intend, then the transaction won’t roll back and the next time you run the test you may hit a unique-ness constraint violation (I know I sure did). To get around this I copied the decorator and simply added a cftry in the transaction with a nice little cffinally around the rollback.
If someone wants to add that and do a pull request, feel free. 