Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Afraid it still doesn't convince me. For testing I would tend to either mock the DB input, or use bag/set tests.

    The efficiency argument doesn't persuade me.

    If you need ordering for the production code then it's needed by the problem domain and it obviously makes sense.

    If ordering is not needed by the production code and just makes the test more convenient to write then it smells to me. You're unnecessarily exposing implementation details to the test suite.

    You're also swapping slower tests for slower production code, which seems a bad exchange.

    Also, unless you're adding indices to the columns in question, this could really slow down the production code quite a bit. Databases can be surprisingly dumb about this sort of thing. So now we're having to add extra indices that are only needed for the test suite - slowing down the commits and updates!

    Finally if we decide at a later date that some sort of ordering is important, and that ordering differs from our 'test order', then all of our tests break. Nasty.

    • I think I should have been clearer about the "apply logic as early as possible" rule. I'm not advovating applying unecessary logic. I'm advocating applying the logic as early as is reasonable. If you need your database records sorted, sort them in the database, if possible. This discussion, to be quite frank, came from me working on some code which returns records in database order and is sorted after it's fetched, but this led to places in the code where it should have been sorted, but wasn't. I was v