Add native Selenium support to django.test framework.

I'll be working on this over the next few weeks. Hoping to have a patch ready by end of October.

The implementation I'm planning on going with is to create a unittest.TestCase? subclass for selenium tests that defines setUp and tearDown.

Then patching the ./manage.py test to check for those subclasses in myapp.tests. This means that each test class defined will bring up a new browser window and run all tests in that class.

The user will need a standard place to define the location of their browser application. I'll be writing in some sane defaults but they are really just guesses since we don't know which browser the user wants to use or if it's installed in the default location. Where is a good place for the user to define this variable?

Wow, I'm very excited to see what you come up with!

I don't think you need to have a user setting for the browser app since I'm pretty sure that the webbrowser module will figure out what the user's default browser is. If for some reason that doesn't work, however, I'd say the settings file is the right place for those options.

FYI, Jason Huggins, the creator of Selenium, is a longtime Django dude and may be interested in helping you with this. I think he might already have something started.

This ticket now depends on ticket:2879 being accepted and committed.

I wrote the live test server support and put it in the other ticket because it's useful enough on it's own, but this obviously can't be resolved without it.

Based on Jacob's comment -> Accepted

Important update.

After months of trying to make Selenium not break on me every week myself and another developer at OSAF wrote a replacement. It's 100% js and python and will be announced publicly sometime in March, hopefully with a presentation at OSCON.

I'll be happy to create another ticket after March to add support for that system rather than Selenium but I won't be able to add Selenium support in this ticket.

Notes for whoever may write this:

The biggest problem someone else implementing this will run in to is interfacing with the Selenium RC server, and in turn interfacing with the browserbot through the server to get useful information about failures. The SeleniumRC server is in java and fairly unflexible.

It also doesn't support a real RPC protocol for the remote client library, all commands to the RC are communicated over URL parameters passed to the proxy and there isn't a very steady communication workflow between the RPC client and the server OR the RC server and the browserbot. The architecture makes it very pritle and nearly impossible to debug, especially in a continuous environment like an automated build/test system.

Also, you'll want to just maintain your own branch of the python remote client library. The method calls which translate into browser actions are all statically defined in the module, so any custom methods in the user_extensions won't work. It's about 8 lines to write a real dynamic wrapper in getattr to call remote selenium methods, but they won't accept the patch over at Selenium because "we write the file dynamically at build time via XSLT, so it is dynamic and doesn't need dynamic method generation. And we use that then we don't get pretty api documentation". Ewwwwwwwwwwwwwwwwwwwww.

Sorry for not putting my name. The last comment was me :)

ok, closing this as wontfix given the comments above. If someone *does* implement some selenium support then please create a new ticket.

For the record, I wrote liveserver in similar way to WindmillTestCase and integrated it with Selenium, works fine for me. Implemented in trunk of django-sane-testing (will be in 0.2 released this week), works fine for me - just subclass djangosanetesting.cases.SeleniumTestCase? and enjoy self.selenium.