From: Steve Bertrand
> Steve Bertrand wrote:
> > Bob McConnell wrote:
>>>
>>> I have begun the task of automating functional tests for some of our
web
>>> servers. I have had some success using Selenium IDE in Firefox to
>>> capture input sequences, exporting them to Perl scripts, then using
the
>>> Se remote control server to execute them. But I have run into one
minor
>>> problem.
>>>
>>> A basic test is to verify the error message returned when an invalid
>>> password is entered. This test script is shown below. I can run this
as
>>> a simple test, or it can be part of a suite. The command line to
>>> manually run the suite is normally:
>>>
>>> perl -MTest::Harness -e "@ARGV= map glob, @ARGV \
>>>   if  $^O =~ /^MSWin/; runtests @ARGV;" test/*.pl
>>>
>>> Unfortunately, yes this is running on a WinXP system.
>>>
>>> My problem is that we have multiple virtual hosts on that server,
and I
>>> need to select a specific host for each run. So when I run the
harness I
>>> need some way to pass the "tst12.dev" portion of the URL into each
of
>>> the test scripts. I can't see any way with Test::Harness or
Test::More
>>> to do this. If I can, then I have other parameters that need to be
>>> passed in as well.
>> 
>> Do I understand you correctly in believing that you are trying to run
>> specific tests against numerous hosts within a single test file?
> 
> Appears as though I've totally misunderstood what you are after...
> 
> After re-reading, it looks as though you are trying to execute
multiple
> test 'files', and want to supply the hostname (and perhaps other
params)
> into them. Yes?

Yes, I have a 'tests' directory with a growing number of Selenium
scripts that will become an automated regression test. Each time I run
those scripts with Test::Harness I need to pass a server name to each
script. There are other variables I would also like to control.

On my test server there are three hosts that I maintain, which normally
have the current and two previous builds of the application. After I add
or modify a test script, or make a change to the current version, if
there is a test failure I can then run the same test on the previous
versions to find out if they produce the same failure. These test
scripts will be checked into our SCM so the QA and production teams have
access to them as well. In addition, those teams should be able to
record and add scripts that recreate problems they find or any that are
reported by clients. Once fixed, those tests will also become part of
the regression suite.

This reduces the time to run a reasonably complete regression test from
most of a man-week to a couple of hours.

Paul's suggestion of environment variables appears to be the only viable
option I have seen so far.

Bob McConnell

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to