...by mocking the database with DBD::SQLite?
Like with DBD::Mock?
thor
Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come
| [reply] |
Ironically enough, no, not like DBD::Mock. DBD Mock is a mock driver, not a mock database. Very big difference.
It's DBD::Mock's stated intention to make sure the right SQL is executed and the parameters bind to it in the right place. It really doesn't care whether the SQL does what's meant of it or not, or infact whether it works or not.
For me when I'm testing Class::DBI based classes I really don't care what SQL is actually being run, provided it does what I want in a reasonable amount of time. What I am concerned with is when I say 'Give me all the users registered after the 10th of October' that I do get the test users I purposefully created which match the criteria.
The approach I advocate (..and try and use whenever possible, I appreciate it doesn't fit every task) is to have a SQLite-based test database, which I can rebuild quickly before each test. This way I can check things such as 'Can I add a user, and then pull them back out?', 'Can I delete all users, and then get a zero user count?', and 'If I try and add a user which doesn't match the database schema (Duplicate ID, or so on) do I get a reasonable error?'.
| [reply] |
