But at a certain level, I'm still testing DBI, its use of DBD drivers and the DBD::Mock code.

But it is black box testing. Which means you dont know or care the details of what DBI and DBD::Mock are doing, just that they respond to your code as you expect. And truthfully you're not testing DBI/DBD::Mock, but testing how your module works with them, and this is very important thing to test.

If I'm going to depend on DBI+DBD+Mock to be in working order, I might as well go for the gusto and use a DBD driver that does something with the statements against a raw DB file I control during testing.

One of the original design goals for DBD::Mock was that it be in a single file, so it was easily embedded in a module distro. SQLite is not that simple, since it relys on an external C library, which is sometimes asking a lot for people to install.

Regarding the "that does something with the statements against a raw DB file I control during testing" part of your comment.

You can have this same level of control and more with DBD::Mock. DBD::Mock will not throw away your statements, but will actually keep track of them as a list of objects you can get back and inspect. These objects not only hold the SQL, but also any bind parameters, number of results returned, etc etc. You cannot do this by using SQLite, you can only examine the side effects of your code in the database itself, which can lead to an explosion of database code to verify things like INSERTs, UPDATEs and DELETEs.

dragonchild mentioned that you can add result sets in order, but you can also bind your results sets to particular SQL statements as well. This means that you are always guarenteed to get back a particular result set with a particular SQL statment. If you don't get it back, you get nothing, and your test should likely choke. With a SQLite database, you need to check the contents of your resultset before you can decide if something went wrong. This means testing with a higher level of granularity that would be nessecary with DBD::Mock.

While DBD::Mock is far from "complete" it does have a number of other features as well, and as the current maintainer I am very open to suggestions as well as patches if you need it to do more.

-stvn

In reply to Re^4: Automated testing of database classes by stvn
in thread Automated testing of database classes by MrCromeDome

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.