Funktionale Tests und stabile Wireframes

Heute wollen wir mal wieder das Thema der funktionalen Tests anbringen. Wir haben in letzter Zeit ja schon einiges über Selenium und Co. gehört. Heute wollen wir ein wenig auf die Umgebung eingehen, in der man Selenium am effektivsten nutzen kann. Wie sieht also eine Webseite aus, die ich problemlos mit meiner Selenium IDE testen kann.

Kurz vorne Weg nochmal ein ganz kurzer Abriss über das Testen mit Selenium. Was wir damit prüfen sind hauptsächlich Eigenschaften von definierten HTML Elementen wie Divs oder Select Boxen. Wir können also auf das Vorhandensein eines bestimmten Textes innerhalb eines Divs prüfen. Soviel erstmal dazu.

Jetzt muss ich aber erstmal definieren, welches Element meiner Seite diesen Text beinhalten muss. Dank Selenium habe ich da diverse Möglichkeiten. Eine davon ist der XPath des DOM Dokuments, das die HTML Seite repräsentiert. Ein Pfad könnte dann wie folgt aussehen: //div[1]/div[3]/div[3]/a. Nicht wirklich aussagekräftig, aber eigentlich eine Standardmethode. Das Problem dabei ist, dass sich der Pfad bei der Entwicklung der Seite auf mitentwickelt. Falls ein neues Element in den Header der Seite eingebaut wird, dann besteht die Chance, dass sich der gesamte Pfad ein Stück verschiebt. Ein Rechtsshift sozusagen. Xpath ist also nur eine gute Idee, falls die Seite wirklich stabil bleibt. Aber das Internet ist schnelllebig und deswegen können und sollten wir uns das doch lieber abschminken, falls wir nicht bei jeder Änderungen unsere Tests anfassen wollen.

Was wir brauchen sind also stabile Ankerpunkte, an denen wir anknüpfen können. Für ein solches System eignen sich IDs hervorangend. Selenium hat nämlich die Möglichkeit Elemente über den xpath:idRelative zu identifizieren. Pfade sehen dann eben nicht mehr wie oben aus, sonder //div[@id='meineID']/div[1]/a. Der große Vorteil, den wir hiermit gewinnen ist eine erhöhte Stabilität der Tests. Jetzt kann sich die ganze Seite um mein Element verändern, solange mein Pfad von der gegebenen ID zu meinem Element stabil bleibt bin ich auf der sicheren Seite. Und wenn sich das doch verändert, muss ich nur noch einen Bruchteil meiner Tests anfassen.

Was sagt uns das also. Als vorgehensweise würde ich empfehlen bei Neuentwicklung gleich IDs zu verwenden um Inhaltsblöcke einzugrenzen. Es muss nicht jedes DIV eine id bekommen, aber die Gruppe in der es sich befindet sollte eine solche besitzen. Bei Altlasten würde ich jetzt nicht nachträglich alles mit IDs versehen. Einfach bei Bedarf nachliefern. Ich schreibe einen Regressionstest, also brauche ich auch eine neue ID. Ganz einfach.