Automatische testen

Om de kwaliteit van software te garanderen is een goede test van groot belang.

Testen kan behoorlijk wat tijd kosten, vooral als er vaak een nieuwe release gemaakt wordt. Bij iteratieve ontwikkelmethoden is dat bijvoorbeeld iedere maand. Handmatig regressie testen doen is een kostbare zaak.

De oplossing lijkt voor de hand te liggen: automatiseer de testen.

Toch zie ik vaak dat het ook een hele investering is om automatische testen op te zetten en belangrijker nog, om de testen up-to-date te houden. Een unit test is snel geschreven, maar het bijhouden van een grote set van unit tests kost discipline van de software ontwikkelaars. Een eerste vereiste is dat de tests continue blijven werken. Een automatisch bouw proces met monitoring is essentieel. Alle tests groen is goed, een rode test mag niet voorkomen en moet direct worden verbeterd.

Unit tests werken dan ook het best als ze heel lokale tests uitvoeren. Bijvoorbeeld het testen van validatie regels of andere “stateless” functies.

De meer complexe unit tests die gebruik maken van mock objecten voor “dependend objects” zijn al snel bewerkelijk en lijken ook meer op integratie tests.

Waar ik meer waarde in zie is een automatische integratie test. Daaronder versta ik testen die software van voor naar achter testen in een integratie omgeving. Denk dan aan een automatische build waarbij het resultaat ook automatisch gedeployed wordt naar een volledige test omgeving, inclusief applicatie server, queueing software, database en ldap servers.

Door de opbouw van de test omgeving volledig te scripten zorg je ervoor dat je altijd een up-to-date omgeving hebt met de juiste configuratie en settings. Denk aan scripts die de applicatie server inrichten met onder andere datasources en system properties, database setup scripts en initiële data. Door van de juiste settings parameters te maken kunnen dezelfde scripts bovendien gebruikt worden om de hele otap straat in te richten.

Dit lijkt veel werk, maar als deze opzet vanaf het begin van het project wordt gekozen, kan er ook veel tijd bespaard worden. Bijvoorbeeld doordat er minder handmatige configuratie fouten gemaakt worden.

De testen zelf worden geschreven op de user interface. Bij web applicaties kan dit met behulp van tools als selenium of een watir script. Deze tools zijn behoorlijk op ontwikkelaars gericht. Als testers of analisten test cases schrijven kan er gekozen worden voor bijvoorbeeld fitnesse.

Met deze scripts kunnen complete use cases worden uitgewerkt, zoals het aanmelden van nieuwe gebruikers, iets kopen op de website of het invullen en doorlopen van wizards.

Bij deze testen worden alle onderdelen en lagen van de software applicatie geraakt en getest, alsof er een echte gebruiker aan de gang is.

Uitdagingen blijven er, zoals het constateren dat er iets mis is gegaan (plotseling een error pagina in plaats van de volgende wizard pagina). Als het te testen systeem (of SUT: System Under Test) ook met andere systemen communiceerd kan daar gewerkt worden met stubs. Deze kunnen slim zijn en reageren met verschillende responses op bepaalde requests.

Vaak gaat de communicatie met andere systemen tegenwoordig via SOAP over http. Met soapui is dan redelijk eenvoudig een slimme stub of proxy te bouwen. Mijn ervaring is dat soapui stubs, als het er wat meer worden, lastig te onderhouden zijn. Met SOAP stubs in mule esb, met bijvoorbeeld groovy scripts voor de slimme stub, heb ik betere ervaring.

Automatisch testen blijft een hele uitdaging en een behoorlijke investering. Met de juiste tools en een pragmatische aanpak kan je een eind komen.