Vijf manieren om je testcode op te ruimen

Vijf manieren om je testcode op te ruimen

Je testcode werkt, maar daar is dan ook alles mee gezegd. Je bent dagelijks bang dat dit de dag wordt waarop hij niet meer werkt. Tijd om de bezem er doorheen te halen en ervoor te zorgen dat je niet-meer-zo-kleine project de stevige fundering krijgt die hij verdient. In dit blog kijken we naar vijf factoren die jouw testcode onstabiel of langzamer dan nodig maken en geven we je direct een idee hoe je deze mogelijke problemen kunt oplossen.

1. Maak gebruik van duurzame identifiers

Een belangrijk onderdeel van automatisch testen is je tool voorzien van de juiste identifiers. Niet duurzame identifiers zijn bijvoorbeeld locators die je met een “CopyXPath” hebt bepaald. Dit werkt op het moment van ophalen, maar het is sterk afhankelijk van de paginastructuur. Wanneer hier veranderingen in worden aangebracht zal je oplossing niet meer werken en moet je dit overal handmatig aanpassen. Een duurzaam alternatief is gebruikmaken van ID, Name of CSS locators.

2. Reken af met een overvolle class

Een succesvolle test opent de applicatie, test de benodigde onderdelen en verifieert vervolgens deze resultaten. Al deze onderdelen zijn even belangrijk bij automated testing, maar ze in één class zetten is vragen om problemen. Maak debugging en onderhoud in de toekomst makkelijker en verplaats al deze acties naar een eigen class.

3. Minimaliseer je wachttijd

Automatische tests klikken een stuk sneller door je applicatie dan mensen. Hierdoor moet je soms wachttijd in je code bouwen om zeker te weten dat de juiste elementen geladen zijn en getest kunnen worden. Een simpele oplossing is om na interactie een pauze voor een paar seconden in te bouwen. Effectief, maar het maakt je tests vaak langzamer dan nodig.

Hoe je het dan het beste kunt oplossen? Gebruik conditional waiting technieken. Verschillende automation libraries hebben hier goede opties voor. Zie in de video hieronder hoe je met Selenium impliciete en expliciete wachttijden kunt inbouwen.

4. Gooi die veel te ingewikkelde method overboord

Hij begon misschien niet monsterlijk ingewikkeld, maar met dat het project groeide, is ook je method gegroeid. Steeds kwam er een stukje bij, net zolang tot je method nu uit een wildgroei van acties bestaat. Ruim dus niet alleen je class op. Geef elke method ook maar één focus en hou het vooral heel erg simpel.

5. Zeg nee tegen duplicate code

Gemak dient de mens. Het is daarom niet gek dat we in testprojecten veel duplicate code tegenkomen. Vaak moet je veel dezelfde stappen doorlopen voordat je bij het stuk komt dat je wil testen. Een snelle copy en paste is dan zo gebeurd. Maar wat doe je als nu juist deze stappen binnen de applicatie veranderen? Dan moet je dit in elke testcode handmatig aanpassen en dat is natuurlijk een horror scenario waiting to happen.

Hoe je dit oplost? Geef dit soort veel voorkomende code een eigen method. Zo hoef je de code maar op één plek te onderhouden en kun je deze method oproepen binnen de tests die deze code gebruiken.

Wanneer moet je jouw code opruimen?

Misschien wil je na het lezen van dit blog direct aan de slag met het opruimen van je testcode. En dat moedigen wij alleen maar aan! Maar vergeet ook niet een goede balans te houden tussen het nu en de toekomst. Heb je een paar dikke deadlines? Ruim dan alleen de code op die je nu aanraakt, dit geeft je net wat meer ademruimte om deze deadline ook daadwerkelijk te halen. Heb je geen directe deadlines en wat vrije ruimte om aan je projecten te werken? Dan is dit het perfecte moment om je bestaande code een grote schoonmaakbeurt te geven.