Chris McMahon's Blog

Selenesse is the mashup between Fitnesse and Selenium I helped work on some time ago.  I keep encountering this pattern in my selenesse tests, so I thought I'd share it... Every once in a while a test needs some sort of persistent quasi-random bit of data.  In the example below I'm adding a new unique "location" and then checking that my new location appears selected in a selectbox.   This is also a neat trick for testing search, or anywhere else you need to add a bit of data to the system and then retrieve that exact bit of data from somewhere else in the system.  | note | eval javascript inline FTW! | | type; | location_name | javascript{RN='TestLocation' + Math.floor(Math.random()*9999999999);while (String(RN).length < 14) { RN= RN+'0';}} | | note | instantiate a variable and assign the new value to it in a single line FTW! | | $LOCATION= | getValue | location_name | | note | click a thingie to add the new data to the system | | click |...

Before it gets lost in history, I want to riff off Alan Page once again, who made some excellent points .  But as someone who has been designing and creating GUI (browser) tests for a long time, I'd like to address some of those and also point out some bits of ROI that Alan missed.  Making UI tests not fragile is design work.  It requires an understanding of the architecture of the application.  In the case of a web app, the UI test designer is really required to understand things like how AJAX works, standards for identifying elements on pages, how the state of any particular page may or may not change, how user-visible messages are managed in the app, etc. etc.  Without this sort of deep understanding of software architecture, UI tests are bound to be fragile. I've said before that UI tests should be a shallow layer that tests only presentation, and that rarely tests logic, math, or any underlying manipulation of data.  If tests are designed in this w...