Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Followup to: How to test different back ends?

by skazat (Hermit)
on Jun 07, 2007 at 04:58 UTC ( #619734=perlquestion: print w/ replies, xml ) Need Help??
skazat has asked for the wisdom of the Perl Monks concerning the following question:

Hey everyone,

I didn't find a very good answer to my seeking at:

http://perlmonks.org/?node_id=618404

But did come up with an OK ideas that's not too too much playing with dragons.

To recap: I'm trying to make some automated tests for an app that has different options for saving information in the backend.

In my perlcode, these different backends are put together by having a module that holds the shared methods to the object that represents whatever I need the backend for, and then separate modules that hold the backend-centric methods for each of the backends.

the problem with testing these types of backends, is that the backend-centric methods are added at compile time not runtime, since my module that holds the shared methods loads the backend-specific stuff with a:

use base qw(App::Backend::ThisBackend);

Type call.

So, in my testing suite, I now have a few files, instead of one for this specific part of the program.

One is called, "backend.pl" (or, whatever)

And then a test file for each of the different backends.

Those test files basically look like the following. This first example is for a backend that doesn't need anything to be setup, so we just explicitly set the type of backend we're trying to test, in this case a Berkeley DB-type backend:

#!/usr/bin/perl -w use strict; use Test::More qw(no_plan); use App::Config; use App::Config::Backend_Type = 'SQL'; do "t/backend.pl";

Since my backends also use the App::Config and App::Config is in the %INC hash, it won't get imported again, and the variable will be set for them, by this test file.

This is the only part where I'm playing with dragons, since it's not *really* my policy or suggestion that you allow your app to arbitrarily set program global configuration variables, but it does come in handy.

To activate the different backends, I can just add whatever I need to make these different backends work in these test files. For example:

#!/usr/bin/perl -w use strict; use Test::More qw(no_plan); use App::Config; use App::Config::Backend_Type = 'SQL'; require test_helper_utils; test_helper_utils::create_SQL_db(); do "t/backend.pl"; test_helper_utils::destroy_SQL_db();

So basically, the actual tests are imported with do() and the test files themselves just set up the environment.

Since the backends basically have the same API, the tests are the same. Testing all the backends makes sure the different implementations don't get out of sync with each other. This will hopefully stop me from getting so many headaches in the future :)

So that was my solution. Perhaps it could be used as a starting point/pattern for someone else,

Crits?

 

-justin simoni
skazat me

Comment on Followup to: How to test different back ends?
Select or Download Code
Re: Followup to: How to test different back ends?
by TOD (Friar) on Jun 07, 2007 at 05:58 UTC
    i think if you take a look at how ModPerl::RegistryCooker works will give you an answer.

    --------------------------------
    masses are the opiate for religion.

      I'll check it out :)

      -justin simoni
      skazat me

      Are you referring to the, uncache_myself stuff?

       

      -justin simoni
      skazat me

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (15)
As of 2014-07-11 14:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (227 votes), past polls