Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Automated testing of database classes

by MrCromeDome (Deacon)
on Dec 27, 2004 at 16:01 UTC ( #417565=note: print w/replies, xml ) Need Help??


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

Interesting! I wish I'd known about DBD::Mock sooner. I'm (painfully) creating bogus data and then deleting it in my existing test suites. This seems like a more elegant way of doing it.

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.

Thanks!
MrCromeDome
  • Comment on Re^2: Automated testing of database classes

Replies are listed 'Best First'.
Re^3: Automated testing of database classes
by stvn (Monsignor) on Dec 27, 2004 at 16:20 UTC
    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.

    -stvn

      Thank you. Your explanations are really easy to follow!

      MrCromeDome
Re^3: Automated testing of database classes
by revdiablo (Prior) on Dec 27, 2004 at 17:33 UTC
    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.

      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
Re^3: Automated testing of database classes
by dragonchild (Archbishop) on Dec 27, 2004 at 16:16 UTC
    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.

      Never thought about checking the the has_a/has_many relationships. Excellent idea! As are the other suggestions. I don't mean to seem dense - this is just uncharted ground for me.

      Thanks!
      MrCromeDome

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://417565]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2021-03-07 13:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favorite kind of desktop background is:











    Results (121 votes). Check out past polls.

    Notices?