itsalleasy

I plan to have a more cohesive post on the process I went through and some of the specific tweaks I had to make…but right now excitement has the best of me and I’m going to let the keys fall where they may.

Recently, the project I’m on REALLY needed some automated testing. We had (have) a rich web-app (ajax/dwr) and were beginning to feel very uncomfortable without tests…a bit like going “without a net”. We had been researching Selenium for the integration/ajax testing and jsunit for some (although admittedly very few) of the javascript objects/classes/widgets we had written, but nothing automated. It was time…so I dove in.

To make a long story short, what I have today is Selenium integrated jUnit tests. The jUnit Tests look like this:

public class SomeScreenTest_UT extends BaseSeleniumTestCase{
public void testCanSearchOrders(){
open(”/products/search”);
assertNotVisible(”searchResults”);
type(”searchField”, “amber bottles”);
click(”searchButton”);
waitForValue(”searchStatus”, “complete”);
assertText(”resultsMessage”, “Found*”);
}
}

Upon execution, a browser will open to the SeleneseRunner.html and will begin running the tests. It is really pretty sweet. The base test case we’re using will open the login page and login first on setup. Then the tests do their thing and if a selenium assert or command fails, then the junit test fails.

I managed to get this working with Selenium 0.6.0.  I wound up implementing a SocketBasedCommandProcessor (can you guess what it does?) as well as a client to go with it. Extended DefaultSelenium to have SeleniumDriver (I needed to have more control over the url the browser would open…and I didn’t like the name). Also implemented a SeleniumDriverServlet to go along with it (the browser talked to the servlet…which talked to the processor via the client). I was pretty proud of it…even followed (fairly) strict TDD.

After implementing all this, I got to REALLY pouring through the Selenium code (last night) and noticed a few interesting classes…namely CommandBridge and CommandBridgeClient. In short, they do (or appear to do) what my implementation does, just without the sockets. It would have been REALLY nice to know about them first. I honestly felt I was tricked The docs are aparenly out of date and some of the examples refered to code that has been moved. When I couldn’t find them, I though they were just making suggestions So one strike against the docs (btw not even the wiki has any mention of them). Even when reading the package structure, it wasn’t at all clear to me that the ‘outbedded’ package and the CommandBridge (which IS a servlet) were what I needed to get a servlet that talked to an external tomcat process…especially when nothing from the actual servlets package seemed to fit. Go Figure.

But after reading the forums, I’m not so sure the CommandBridge code even works. Aparently the “driven” stuff is undergoing a huge overhaul and is now going to be called “selenium remote control”. Which is good really because these guys have some good stuff under the hood and it just needs to be a bit easier to use. It could use some better names, and packaging…and definitely better docs, but it is still some great work.

Also, just today got Selenium to drive the jsunit tests for the app.  That was cool too…we needed jsunit to run in the build as well and I figured we already had this selenium setup, why not have IT drive the jsunit tests too.  It took some tweaking because jsunit expects to be the top level frame, but it worked.   I should mention that I do prefer to have jsunit run without need of the server running…and we still have that ability, this was just an easy-ish way to get it working with something we already had, just for the continuous integration.  I also know that jsunit has a server bit that ant can drive, but we wanted to be able to make it work just by running the junit test, this gives us that…no need for ant to kick anything extra off, just make sure the local server is running, which it usually is).  The test suite that selenium ‘drives’ is actually a jsp (so there IS one benefit to having the server running) that will scan the js folder for all _UT.html files, and adds the path to them to the test suite.