> I thought of an alternative which might have a number of the benefits of
> this solution with less of the drawbacks.
>
> The idea is to create one big file test file that is run in the normal
> way. Everything would only need to be loaded once instead of N times.
> There wouldn't be the usual pe
On Wed, Dec 07, 2005 at 08:01:39PM +, Mark Stosberg wrote:
> So I'm now using and liking Selenium after several recommendations from
> this list. I'm interested to know how other people integrate it with a
> traditional perl test suite. It seems like there are two possibilities:
>
> http://s
On 2005-12-07, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>>
>> Limitations and Caveats with the system:
>>
>> * Scripts that muck about with STDIN, STDOUT or STDERR will probably
>>have problems.
>>
>> * The usual persistent environment caveats apply: be careful with
>>redefined subs, glo
Hello,
So I'm now using and liking Selenium after several recommendations from
this list. I'm interested to know how other people integrate it with a
traditional perl test suite. It seems like there are two possibilities:
http://selenium.thoughtworks.com/
1. Use "prove" as the primary test sui
On 2005-12-05, Michael Graham <[EMAIL PROTECTED]> wrote:
>
> This should be compatible with regular (non-PersistentPerl) use as well.
>
> ...
>
> Limitations and Caveats with the system:
>
> * Scripts that muck about with STDIN, STDOUT or STDERR will probably
>have problems.
>
> * The usual p
