A test using mock objects would not be a very good test.
Why do you say that? What really makes it different from testing with the real object? When DBD::SQLite writes to the database, is that testing Class::DBI or is it testing DBD::SQLite? Class::DBI really should not care what happens after it sends its SQL to the DBD driver, and to properly test Class::DBI, you should check that it generated the SQL you expected it to. By testing a SQLite database you are not really testing Class::DBI, but the side-effects of Class::DBI's interaction with DBD::SQLite.
So why not use something like DBD::Mock? It behaves pretty much like your standard DBD driver, and you can both feed it mock results and read back a history of SQL statements you have run. IMO this would be a much more effective (and less intrusive) test of Class::DBI's functionality. I have actually been using DBD::Mock to test our inhouse OO-Relational mapping tool and I would never go back to using a real DB to test. It has not only increased the quality of my tests, but it takes me less than half the time and code it did to test it with a real database. I recommend it highly.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|