Re^2: Test::Mock::Class::DBI

in reply to Re: Test::Mock::Class::DBI
in thread Test::Mock::Class::DBI

...by mocking the database with DBD::SQLite?

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

Comment on Re^2: Test::Mock::Class::DBI

Replies are listed 'Best First'.
Re^3: Test::Mock::Class::DBI by Molt (Chaplain) on Jul 25, 2005 at 13:58 UTC
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]

Replies are listed 'Best First'.

Re^3: Test::Mock::Class::DBI
by Molt (Chaplain) on Jul 25, 2005 at 13:58 UTC

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]

In Section Meditations