Selenium and text-based testing

Ever since I saw PyUseCase I’ve been longing for a port which runs with web apps. I’ve been thinking briefly about actually doing this, using Selenium as the engine/driver. To make it usable, I guess I’d have to make TextTest ignore certain aspects of the DOM/HTML-tree (such as automatically-generated ID attributes, and positions of nodes, a dialog “window” for instance).

Today I saw the Tellerium IDE, which is a plugin for Firefox, and that got me even more motivated to actually go ahead and try to move towards a WebUseCase port for xUseCase and TextTest. Now I just need to find the time to make this happen …

PyUseCase för ExtJS

Häromdagen var jag på GothPy-möte och fick se och testa på PyUseCase. Efteråt funderade jag på det 18-månadersprojekt (~8 utvecklare) jag nyss avslutat där ExtJS varit GUI-ramverket i applikationen (dvs en Rich Internet Application).

PyUseCase för ExtJS

  1. Det hade varit väldigt användbart.
  2. Jag har inte sett något liknande för webb.
  3. Jag tror inte att det är omöjligt …
  4. … men det kan kräva en hel del kunskap (om Selenium IDE) och kod att få till. :/

Jag har ännu inte kollat på Selenium 2. Jag har inte testkört Bromine utan bara tittat på dess screencast. ** I början av projektet jag satt på pratade vi dock om att det hade varit fint att ta oss till den nivån att man hade selenium-test som verifierade use case. Det närmaste jag såg ett verktyg som skulle kunna stödja det var STIQ, men organisationen ville inte testa detta – att använda Selenium var tillräcklig risk i projektet tyckte man.

** “Management can look at the icons ” 7 minuter in i filmen :)

Versionshantering

Varken STIQ eller Bromine verkar dock versionshantera testen, eller gruppera dem i “detta är use-casen för sprint 10”, och det är något jag känner att jag saknar. Under de 18 månader vi jobbade så byggdes flera funktioner om, så i sprint 10 kanske vi stödde 15 Use case, medan sprint 11 bara klarade 12 eftersom 3 skrevs om.

Sättet vi hanterade det på var att kommentera bort test case från testsviten. Inte snyggt, men eftersom Hudson mailade oss varje gång testen inte fungerade var vi nästan tvungna …

Avslutande tankar

  • Det jag gillar med Bromine är kopplingen till krav/use case.
  • Det jag gillar med STIQ är wiki-hanteringen och att man försöker abstrahera testen till logiska enheter/interaktionssteg.
  • Det jag gillar med PyUseCase (för GTK) är hur inspelningen mappar till logisk enhet/interaktionssteg. Separationen med texttest är inte dum, eftersom valideringsbiten faller bort från stegen som behövs för att utföra use caset. Att ha två representationer av GUI:t (en ASCII-art och en verklig) är dock inte intuitivt för mig och känns som ren duplicering. Kanske är det ett nödvändigt ont man får acceptera för att få rena “use case test”?
  • Med ett UI-ramverk som ExtJS borde man kunna lyssna på komponenter på samma sätt som PyUseCase gör med PyGTK. ASCII-art-rendreringen server side (eller iaf någon logg) är jag tveksam till.

Ext JS, Selenium and sub menus

Ext JS menu with IDs
Ext JS menu with IDs

Had an issue with Selenium not opening sub menus properly. Actually had to make a test page in order to convince myself that it would work. Testing is hard, when autocomplete in the Selenium IDE won’t help ya! :-D

The fact that Selenium can’t verify classes (when there’s more than one) on an element is tragic and very limiting …

Ext.TabPanel and mouse clicks

Had issues when replaying clicks on a Ext.TabPanel’s tab. The Selenium IDE recorded the click event pretty well (actually, the second click was recorded – perhaps only when the tab was the active one (not investigated thourougly)), but the click action didn’t trigger the tab panel to swich panel. After some great deal of testing, the one Selenium action that does work is mouseDownAt.

Browsers tested: Internet Explorer 6, Internet Explorer 7, Safari 1.5 on Mac, Firefox 2, Firefox 3.

Ext.form.ComboBox dropdown trigger

The Ext.form.ComboBox is almost testing friendly. Not everyone can do what we did, but we could and it made testing sooo much easier (and human readable).

onRender: function(ct, position) {
  Ext.form.TriggerField.superclass.onRender.call(this, ct, position);
  this.wrap = this.el.wrap({cls: "x-form-field-wrap"});
  this.trigger = this.wrap.createChild(this.triggerConfig ||
    {id: this.id + '_trigger', tag: "img", src: Ext.BLANK_IMAGE_URL,
    cls: "x-form-trigger " + this.triggerClass});
  // rest is as in original

And also

initList: function() {
  var cls = 'x-combo-list';
  this.tpl = '
{' + this.displayField + '}
'; js.ib.ui.CWComboBox.superclass.initList.call(this); },

An alternative is to use CSS selectors, as described by CableDawg on ExtJS’ forum.