We are working on doing this using JUnit. We have a couple of hurdles to overcome first though: 1 our app is in a frameset, 2 our app is an aincient mix of perl, java and j2ee running in three different containers. I think we are going to need to hack selenium a bit to get it to work. I should have some time to work on this properly over the next few weeks. I'll post back when we have made some more progress. Thanks for the tips Greg
Alex Borshik
CRD Application Developer
| CBEC | Glasgow | CRD Build Team | (: +44 141 GDP 228 5211 | Ê: +44 141 228 5005 | 
pwp
| Greg Fodor <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 03/08/2005 02:48
|
To: selenium-users@lists.public.thoughtworks.org cc: Subject: Re: [Selenium-users] cruise control |
We've done it. It was a little rocky getting it to not freeze up etc (we
use the .NET driver with NUnit.) Now that it's all fixed up though,
we've had no problems with it and it really helps us catch regressions
regularly.
To save you some headaches, here's some stuff I suggest you do if you
are running it in driven mode off of CC.NET:
- Set the browser process priority to below normal in the SetUp of each
test, this makes it so your unit test still gets some CPU since selenium
pushes the browser up to 99% when it's in its message loop. XPath, etc
seem to run faster overall if you do this as well.
- Use Browser.Close() at the end of each test to minimize the changes of
a rogue test leaving the context of the test in the wrong window, etc.
We also had problems when using Browser.Launch(), so make sure you use
Browser.Open() instead.
- In your build script, make sure you kill any instances of
firefox/IE/your browser for Selenium before running the tests, so there
is a fresh slate each time. (We use a small program we found on the
internet to kill it from the command line)
- We've found that a good way to get back exception data, stack traces,
etc from Selenium if the web site throws an error is to encode it into
the IDs of a few input controls on the page and pull it out and decode
it using GetAllFields. This seems to be the only reasonable way to do
Browser->Driver communication (as opposed to the normal Driver->Browser
communication.) There are a few gotchas, you need to make sure you
encode the IDs in such a way that they don't include bad characters such
as : and # and you need to break it up until bitesize chunks so selenium
can get it back.
- Make sure you have a reasonable timeout in cruise control, since often
times a failing Selenium test fails because someone forgot to switch the
context back from a popup, or there was a bug in their commands being
sent. When this happens, the driver will just hang there indefinitely,
so you need to be sure you'll get a Build Failed message ASAP.
We've never gotten it working with IE, we Selenium test exclusively with
FireFox.
Hope this helps,
-Greg
Jamie Orchard-Hays wrote:
> I'm curious how any of you have integrated Selenium tests into Cruise
> Control.
>
> regards,
>
> Jamie
> _______________________________________________
> Selenium-users mailing list
> Selenium-users@lists.public.thoughtworks.org
> http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
>
>
_______________________________________________
Selenium-users mailing list
Selenium-users@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
_______________________________________________ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
