What makes a Class::DBI object different from any other object? You can mock both with Test::MockObject
| [reply] |
| [reply] |
What about the article on perl.com about Test::MockDBI? Test::MockDBI sounds fairly close to what you were looking for, although maybe not exactly it.
| [reply] |
With Class::DBI being fairly simple to use would it be possible to do what you're intending by mocking the database with DBD::SQLite?
I appreciate that it keeps the Class::DBI layer intact, which is not always what you need, but I feel this achieves most testing requirements of these systems with minimal pain.
| [reply] |
...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] |
