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/