<div dir="ltr">Thanks for the reply, Catch - good stuff. I'm going to take a look at what it would take to get Selenium RC to work with simpletest instead of PHPunit (the unit testing framework the Selenium RC docs refer to).<br>
<br>An interesting note about Selenium's ties to Drupal - the new AutoPilot 2.0 beta - which was just released in time for Drupalicon - <a href="http://twitter.com/workhabit">http://twitter.com/workhabit</a> heavily relies on selenium (e.g., selenium's macro recorder/playback is being used in this case for handling change management [pushing changes from dev to staging to production], so apparently it is not just for acceptance testing!). <br>
<br>- Caleb<br><br><br><pre>I suggested an automated javascript testing framework for gsoc, was thinking<br>watir rather than selenium based on a few discussions about both, but it<br>didn't go anywhere:<a href="http://groups.drupal.org/node/9511,">http://groups.drupal.org/node/9511,</a><br>
<br>While I'd love to see testing with Selenium or Watir or some other browser<br>remote control that can handle stuff that simpletest or straight up<br>javascript unit testing can't, like cwgordon said, it's a matter of effort<br>
and returns.<br><br>The testing framework we have in core has the advantage that anyone can<br>download and run tests without needing to install other software, tests can<br>be written in PHP, and we're getting close to the tipping point where our<br>
coverage is high enough to start finding regressions before they're<br>committed.<br><br>On the other hand, and unfortunately, at the moment we don't have that many<br>jQuery intensive patches - yes, it's really annoying trying to get<br>
cross-browser tests when a new jQuery is released, but that's once every few<br>months - so in terms of saving click around time SimpleTest is giving higher<br>returns at the moment. While it might appear to be a lack of interest at the<br>
moment, it's more a case of 1. a lack of resources (the 'testing brigade' is<br>still pretty small) 2. a need to get the testing framework we actually have<br>up to a point where it begins to actually save some work - it'll only do<br>
this when we're closer to 100% test coverage and tests are being run on<br>patches automatically via <a href="http://testing.drupal.org">testing.drupal.org</a><br><br>That said - it's very clear that the core testing framework can't cover<br>
everything, so extending it would be the natural next step - and given the<br>amount of time and work it's taken to get to where we are now, starting<br>early surely wouldn't hurt.<br><br></pre></div>