When you mention API testing, are you implying Class::DBI? All of my classes are descended from Class::DBI - I've added no functionality to it.
API testing means that you should test how your class might be used. If a user calls the view_table method, it will spit out the data @blah. Even if Class::DBI does all the dirty work, you still want to be sure that your return values comes out as you expect. In a way this is black box testing since you are not examing the internals of Class::DBI (where the work is being done), but only checking that given the proper input, your methods return the proper output.
And then of course, you can use DBD::Mock to check that the right SQL statement was produced, and all that good stuff too. In a way this is also testing that Class::DBI is doing it's job correctly, although maybe more grey box testing.
| [reply]
[d/l]
[select] |
| [reply] |
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.
| [reply] |
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.
| [reply] |
Well, you obviously are doing something more than just Class::DBI is doing, otherwise you wouldn't have subclassed it!
Maybe you could test that the My::DBI::Foo class does or doesn't have a bar() method or a 'baz' column. Maybe you need to test your collections to make sure the right thing comes back? has_a()/has_many()/might_have() all need tested to make sure you're returning the right class.
These tests are going to be very simple and should run very quickly. But, they provide some sort of safety net for you to program against. Remember - most safety nets are built with twine. :-)
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
| [reply] |