http://qs321.pair.com?node_id=652233


in reply to Re: SQL configurations in automated testing
in thread SQL configurations in automated testing

I wouldn't care about what, testing it? :)

DBIx::Class looks interesting, but it's a HUGE project, compared to my homely program. I can count the number of alternative methods needed to work with the various backends on my project on one hand, so I'm not sure quite a large solution is needed quite yet.

I may have missed it - is there an auto-configuration part of DBIx::Class for testing? Using it for this project looks somewhat like a rewrite of the program, unfortunately. The program is older than DBIx::Class :)

 

-justin simoni
skazat me

  • Comment on Re^2: SQL configurations in automated testing

Replies are listed 'Best First'.
Re^3: SQL configurations in automated testing
by dragonchild (Archbishop) on Nov 21, 2007 at 21:24 UTC
    The point is that DBIC already does all that testing for you with regards to how a given DBMS will work. All you care about is making sure that you make the right calls to DBIC. To test that, you can go ahead and use DBD::Mock to test your SQL. Alternately, you could work with the DBIC folks - they've almost got a testing framework for use with DBIC applications all done.

    The point is that you use a tool so that you don't have to maintain a given subsystem. If you don't have to maintain it, you don't have to test it. So, you can test a single RDBMS (mysql or pg, for example) and be reasonably certain that it will all work in others.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

      I see.

      That's quite interesting.

      For this project at least, it doesn't seem to be quite a good fit.

      But, it still looks like there's no one quite to run the test suite on a server you're installing on. I'm thinking of weird dragons and discrepancies between the environment of the server I'm developing on and the (thousands) of different servers that may well have it installed on. That still doesn't seem to be a problem DBIx::Class solves (or advertises, I don't think)

       

      -justin simoni
      skazat me

[reply]
        you're quite right in that even the same operation can work quite differently on the same db engine but on different architecture. the db engine vendors do try to make things as portable but they're never 100%.
        on a side note in regards to different db engines, it's interesting to see some not so minor SQL standard implementations by the different vendors. some of this is documented in Joe Celko's book "SQL for Smarties"
        in terms of further developing your test suite...maybe it could be made more black box like by having a config. As for checking whether a db engine exists on a machine or such, you could run basic sanity check before running tests proper. The sanity check typically written in "eval" style defensive coding to connect to db etc.
        or maybe i'm missing the point entirely?
        the hardest line to type correctly is: stty erase ^H
[reply]

In Section Seekers of Perl Wisdom