My opinion about through-the-web-GUI enterprise-app-testing, in general, is that it is like driving on ice in a blizzard: not something you want to do lots and lots of, because sooner or later you’ll get into deep trouble. But given your context (living in MI, for me), driving on ice in the snow is something that is useful to know how to do well, in a pinch.

I’ve blogged in the past about low-TCO (Total Cost of Ownership) Selenium RC testing in general, and about  how much of your automated testing budget should be allocated to different kinds of testing at different points in an agile transformation. Of late, I have been helping teams learn to use Selenium RC, in Java, to test web apps through their GUIs. Once the above Caveat Tester is spoken, I help them do the Selenium RC testing that they feel they MUST do as well as possible.

I have been diving more deeply into it for several clients recently, and finding and refining some useful patterns I had not needed or found before (with the help of several colleagues). And, admittedly, some of what I am doing is refining my old patterns in response to things like Refactoring pressure. In general, I am devising increasingly DRY Object Oriented Selenium RC Java patterns. I recently presented on them at Agile 2010.  Using git, you  can checkout the code that illustrates these patterns from github here.

I intend to share each of these patterns with you, each in its own blog post, in coming weeks.

So watch this space for blog posts covering the following topics:

• Clean, clear test methods
• Separating DRY test-framework code from “wetter” tests, and separating reusable, generic test-framework code from biz-domain-specific framework code
• Wrapping Selenium and other frameworks in Facade/Decorator that provides static Singleton test framework access.
• Pushing all framework static Singleton references down into base classes and html element classes.
• Biz-Domain-specific Page Objects that are “lazy loaded” and self-verifying, and that encourage Dry OO test code
• Always using CSS as a DOM element locator strategy; never using XPath.
• Injecting the entire jQuery framework into pages under test, in order to verify visibility of elements that appear after dynamic html or Ajax calls.
• Generic HTML Element objects (ala HtmlUnit’s API) that encourage Dry OO test code
• DhtmlLink and PageLink Factory classes that are instantiated with the Page Object classes they should “go to,” and that automatically return those objects when “clicked”.
• Pushing out access to common elements across several pages to static Singletons on base page classes.

The code I link to above illustrates all of these patterns, expecting (for now) to run against a demo instance of a Rails app called FatFreeCRM, which is available for you to play with at http://demo.fatfreecrm.com/login.