>>>>> "BM" == Bob McConnell <r...@cbord.com> writes:
BM> From: Philip Potter >> On 6 April 2010 16:52, Bob McConnell <r...@cbord.com> wrote: >>> I have a test harness set up with a series of Selenium test scripts. >>> Each script tests a specific scenario on my web site. But I have some >>> scenarios that I want to test multiple times with different data BM> entered >>> each time. Currently I am using environment parameters to pass the BM> test >>> data into each script. But that doesn't work for multiple passes, BM> since >>> I have no way to save the base data and restore it after modifying BM> it. >>> >> [snip] >>> >>> How can I make this loop through some tests multiple times with >>> different sets of data each time? BM> After a great deal of reading and speculation, it looks like YAML is the BM> way to go. I will have to move the loop inside each test script, and BM> iterate thorough the records read. The biggest problem is that the plan BM> is no longer fixed, so I do lose some auditability, but I don't see a BM> cleaner way to do this. i call this table driven testing. i have done it for several of my modules which required many variations on a theme. check out the test code in Sort::Maker. it does a double level loop on each test with different data and different arguments (sort methods). it doesn't need external files as the args are in a perl data structure. the concept is very simple and easy to implement. it needs to be customized for your testing but you can steal the overall design from there. BM> I will end up with a test.yml file (which I didn't even know existed BM> when I got the referenced message) defining an array of hashes, each BM> with input for one iteration of the test. I'll loop over the whole BM> scenario, stepping through the array until it is gone. you can even use perl itself. just write a perl data structure and call do on it. it can be an anon array or hash which is the returned value. no need to learn yaml or load another module. you can also slurp/eval the file (which is what do does anyhow). or do what i did and put the data in the test file, write a shared driver module which you load and then you write a simple wrapper to run the tests. also you can still do a plan. all you need to do is prescan the data to count all the tests (and variations) and send that to the test plan. i do that too. BM> Then the next step will be to figure out how to do fuzz testing on those BM> forms. The response to submitting a form will change with each incorrect BM> input, which will present a challenge in how to detect which response is BM> correct and how to react to each one. you write pairs of inputs and expected outputs in your data. not tricky at all. in my structures i have input data, golden sort code (which is supposed to generate expected results) or expected results. you then compare the expected to actual results for the ok() call. this is very easy for almost any kind of test where you could call ok(). this whole concept is much easier than you think. you do need to change how you write tests but it makes it very easy to make many many variations to cover all your cases. the common code is factored out into the driver sub and the individual variations are stored in your table (usually an array of hashes). uri -- Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
