in reply to Re^2: Automated testing of database classes
in thread Automated testing of database classes

I wish I'd known about DBD::Mock sooner. I'm (painfully) creating bogus data and then deleting it in my existing test suites.

I do not wish to take anything away from the fine post by dragonchild, because it is good advice. DBD::Mock is a lightweight way to test your API, as he said. But, as he also said, "That should be a good start."

In other words, it is not the whole solution. You should still be testing the database itself, in some capacity. You want to make sure the connection works, the database is returning the right type of data, the table structure works as expected, etc. So once you get a nice suite of API tests with DBD::Mock, you are still probably going to end up creating bogus data and deleting it, in order to further test your application's database interaction.

Please do not think I'm saying DBD::Mock is pointless, though. It allows you (and your test suite) to narrow down where a problem lies. For example, if you are getting incorrect data from the live db test, but correct data from the DBD::Mock test, then you know there might be something wrong with the database. This type of troubleshooting information is extremely useful.

  • Comment on Re^3: Automated testing of database classes

Replies are listed 'Best First'.
Re^4: Automated testing of database classes
by stvn (Monsignor) on Dec 27, 2004 at 19:26 UTC

    revdiablo makes an excellet point. You can use DBD::Mock for your unit tests (tests which only test the class itself in isolation (or at least as isolated as possible)). But when it comes time to do integration tests (tests which test the interaction of classes in the larger system), then you will likely want to use a real database.

    -stvn