Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I may have missed a point where you said you couldn't do this, and if so, I apologize, but: can you wrap every test file in a transaction and then rollback after each test? That's the best speedup I've found for this kind of thing.
    • I think that's very bad idea which, unfortunately, has gained some tractions with testers. The major error is that it says "hey, we're going to alter our code's behavior". Now you are no longer testing your code. You're testing a globally modified version that simply doesn't behave like your real code. It's almost like developers using SQLite to test their code which relies on MySQL -- you're no longer testing your code, you're testing a simulacrum.

      What if want to test commit/rollback? What if you have

      • Now you are no longer testing your code. You're testing a globally modified version that simply doesn't behave like your real code.

        This is only true if your real code involves using more than one connection to the same database. Lots of code doesn't need to do that in a testing context.

        What if want to test commit/rollback?

        The previous comment already addressed that, unless you're stuck on a database without them. (I've only done this on postgres.)

        What if you have multiple processes that need to communicate? (One process adds data and another one, in a Web spider, fails to read the uncommitted data because it's in another process)? I accept that sometimes we need changes in code behavior to account for tests, but only if those changes are minimal in scope.

        This seems like an argument for not using this technique all the time, not like an argument for never using it.

        It sounds like you're saying "this won't work for my case, so it's always a very bad idea".

        • There may very well be cases for which this is appropriate so I would not tell someone else "never", but this is one of those things that I've been bitten with very hard in the past. Accidental commits. Accidentally having more than once connection (very common with Web tests). Not being able to properly test bits of the code which commit, etc. If it works for you and you're comfortable with your results, that's fine. It's hurt me far more than it's helped me, so I just prefer not to use this technique. Resetting the database before each test has worked wonders for me, so I'm happy to stick with this :)

          • Accidental commits. Accidentally having more than once connection (very common with Web tests).

            Yeah, there are definitely fiddly bits, and a lot of times it's not worth the effort.

            Not being able to properly test bits of the code which commit, etc.

            I don't understand why you keep saying this. Do you not believe me and jplindstrom when we say it's possible to test commit/rollback using savepoints to do nested transactions?

            • To be fair, I've never worked with nested transactions before. I am aware of them and what they can do, but I've never tried it out. I'm looking forward to seeing the results of his "gold card" work with this (we're on the same team at the BBC so I'll be able to see it firsthand).