Re^2: Automated testing driving me nuts...

Yes, i know, but i only need the testsuite to ignore the commands it isn't aware of, i want to be able to have a set of standard automated tests, to ensure at least minimal working functionality.

update Ok, taking into account what you said, right now wtr looks verry promising, you have to code ruby, but i don't think there is a problem with it for anyone who likes perl ;-), and it works directly in your browser (only tested ie for now).
I've set-up a simple test in less than 5 minutes that i still wasn't able to do with httpunit...
I still have to evaluate Siege as well, but that comes later.

"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise." - Larry Wall.

Comment on Re^2: Automated testing driving me nuts...

Replies are listed 'Best First'.
Re^3: Automated testing driving me nuts... by dragonchild (Archbishop) on Jun 13, 2005 at 12:47 UTC
In other words, you want to test a specific subset of your application, where "specific" means "the stuff someone else doesn't support testing". The honest way to do this is have your JS have a ishttpunit flag, similar to the isIE and isNS flags, that will remove all stuff that httpunit doesn't support. Frankly, I think you're going about this the wrong way. On the server, you test the server. So, verify that the JS being generated is correct. Verify that the various Perl components are doing the right thing, both in isolation and together. Then, on your target client machines, run the brower(s) you expect to support through some scripted interface and test that. You cannot test client interactions on the server. Not even a little. You need a client to test client interactions. In general, if you think something isn't in Perl, try it out, because it usually is. :-) "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"	[reply]

Replies are listed 'Best First'.

Re^3: Automated testing driving me nuts...
by dragonchild (Archbishop) on Jun 13, 2005 at 12:47 UTC

The honest way to do this is have your JS have a ishttpunit flag, similar to the isIE and isNS flags, that will remove all stuff that httpunit doesn't support.

Frankly, I think you're going about this the wrong way. On the server, you test the server. So, verify that the JS being generated is correct. Verify that the various Perl components are doing the right thing, both in isolation and together.

Then, on your target client machines, run the brower(s) you expect to support through some scripted interface and test that.

You cannot test client interactions on the server. Not even a little. You need a client to test client interactions.

In general, if you think something isn't in Perl, try it out, because it usually is. :-)
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

[reply]