http://qs1969.pair.com?node_id=489987

ghenry has asked for the wisdom of the Perl Monks concerning the following question:

Dear Master Monks,
I have a web application I need to test, and wanted some advice before I start writing. I have two ideas that follow;

1. Custom Module:

2. Perl Test files:

I have recently bought Perl Testing: A Developer's Notebook and Perl Best Practices, so they will probably help me out on the finer points ;-)

I think that maybe 1. would be the best way to go, as it would be a proper module, easier to manage, but might duplicate testing, i.e. testing the test functions. But then again, you can't test enough.

I will probably be using a bit of WWW::Mechanize and HTTP::Recorder to start me off.

I know a lot of Monks would have been in the same situation as me at some point, so if one of you kind souls would put me on the right path, I would be very grateful.

Thanks,
Gavin.

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

Replies are listed 'Best First'.
Re: Application Testing: Custom Module or Perl Test Files?
by xdg (Monsignor) on Sep 07, 2005 at 20:51 UTC

    It's also fairly common to have a hybrid between scripts and modules. You can create .t files for individual sets of tests, but place common functionality into a .pm file within the t/ directory that each of your .t files uses. As an extensive example of how this might work, see Test::Class -- though it's perfectly fine to just create a simple module with some helper functions, too, so you don't repeat them in your test scripts.

    Personally, I think using Module::Starter to create your test module is overkill, as most of Module::Starter is oriented to creating a framework for packaging up modules for distribution which you don't really need.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      Personally, I think using Module::Starter to create your test module is overkill, as most of Module::Starter is oriented to creating a framework for packaging up modules for distribution which you don't really need.

      I've been using ExtUtils::ModuleMaker instead of Module::Starter, though both focus on getting a developer started.

      i'd disagree about them being overkill, though, because they do create the basic organizational structure (directories, stub test files, etc) to get one in the habit of testing.

      additionally, at least ExtUtils::ModuleMaker has options to create multiple modules, which is *very* convenient.

        The more general point I was making was that when making a module to help with testing some other module or application, creating it with a whole distribution skeleton (README, MANIFEST, Changes, etc.) is unnecessary, whether using Module::Starter, Extutils::ModuleMaker or h2xs or something else entirely. It's sufficient to just create a .pm file and stick it in t/ directory.

        (N.B I'm the author of ExtUtils::ModuleMaker::TT, so, yes, I'm a fan of the ExtUtils::ModuleMaker school. And kudos to jkeenan1 for his recent updates!)

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        I couldn't find where in the ExtUtils::ModuleMaker docs it mentions creating multiple modules, but in Module::Starter it shows it:

        module-starter --module=Foo::Bar,Foo::Bat \ --author="Andy Lester" --email=andy@petdance.com

        Maybe I completely missed it?

        Oh, and I like the look of Module::Starter::PBP:

        Module::Starter::PBP - Create a module as recommended in "Perl Best Practices"

        Walking the road to enlightenment... I found a penguin and a camel on the way.....
        Fancy a yourname@perl.me.uk? Just ask!!!
Re: Application Testing: Custom Module or Perl Test Files?
by jimX11 (Friar) on Sep 08, 2005 at 04:11 UTC

    Using HTTP::Recorder to help start building tests with WWW::Mech is smart. Using Test::WWW::Mech is better. But using Test::WWW::Mech inside of Apache::Test is really powerful.

    Apache::Test, a subproject of the Apache HTTP Server Project, provides the framework for what web apps need. What do web apps need? Well, a configured web server.

    Configuration to determine:

    • the location of the log files
    • the location of the htdocs
    • maybe the location of your perl modules
    • maybe you have specific configuration, I like my cgi-bin outside of my htdocs, so I often alias the cgi-bin dir.

    You don't really care about those things when you're testing. You just want to think about the tests.

    Apache::Test (A-T) takes care of all of that for you, you just provide the tests.

    And A-T works great with CVS (and SVN). Sure you can use test suite build only on Test::WWW::Mech in cvs, but it's often inflexible - the tests are often in a different location that the web server. A-T essentially bundles the httpd.conf with your perl modules and your perl scripts and your tests. Everything you need is in one place. So with A-T you can just check out a copy of your code in a different sandbox and hack away. No need to tweak the httpd.conf files to point to a different location.

    A-T, and test suites in general, make maintenance so much easier. Say you have a mod perl 1 app and want to move it to mod perl 2. If you have a test suite (either using A-T or not), you can run the test suite on it. But running the test suite on different version of perl and apache is really easy in A-T. I've seen A-T guru Geoffrey Young quickly and easily run a test suite on different combinations of version of Perl and Apache.

    If you develop your web app with care you'll almost always have tests that test things outside of the web app. A-T can handle that for you to.

    I'd say the biggest hurdle is setting up A-T, but you only do that once (per server configuration). And there are skeletons to help you do that.

    A-T works with perl cgi scripts, Apache::Registry, mod perl and even php.

    The docs are helpful - I'd like to help reorganize them but have done nothing at all to help yet.

    Geoff, who is often helpful on the A-T mailing list wrote this article.

      I will definitely be researching Apache::Test.

      I like the look of Flood, as a profile-driven HTTP load tester.

      Walking the road to enlightenment... I found a penguin and a camel on the way.....
      Fancy a yourname@perl.me.uk? Just ask!!!
Re: Application Testing: Custom Module or Perl Test Files?
by moot (Chaplain) on Sep 07, 2005 at 22:54 UTC
    You may also wish to check out Test::WWW::Mechanize, which automates some parts of testing sites. I've had good success with subclassing Test::Unit and writing a custom method for each feature I want to test, with a Test::WWW:Mechanize instance created in set_up() or new(). I know that Test::Unit is largely deprecated in favour of Test::Class, but it's a useful module.
Re: Application Testing: Custom Module or Perl Test Files?
by water (Deacon) on Sep 11, 2005 at 13:53 UTC
    Have been doing TDD for about two years now, but just discovered Test::Class this week (from reading the Testing Notebook, in fact!) and it is really great.

    Recommended highly.