TestAutomatisering & PerformanceTesten

Regular Expressions en Testautomatisering, twee problemen of juist een oplossing?

Bij geautomatiseerde checks wil je regelmatig een verwachte waarde controleren tegen een actuele waarde. Vroeg of laat kom je dan in aanraking met wildcards: Je wilt bijvoorbeeld weten of de tekst “Er zijn 42 resultaten gevonden” voorkomt, maar het aantal, hier 42, kan variabel zijn. Van 42 wil je dan een wildcard maken.

De meest gebruikte wildcard language is de regular expression. Binnen het testautomatiseren gebruik ik graag regular expressions:

Maar eigenlijk is de belangrijkste reden:

Wat betekent dit? Je hoeft de check niet programmatisch af te handelen. Laten we kijken hoe we dit programmatisch zouden kunnen afhandelen:

public void CheckCorrectResultAmountMessage(string actualText) 
{
    // Check the start of the text
    Assert.IsTrue(actualText.StartsWith("Er zijn "));

    // Check the end of the text
    Assert.IsTrue(actualText.EndsWith(" resultaten gevonden"));

    // Grab the amount
    var amountText = actualText.Replace("Er zijn ", "").Replace(" resultaten gevonden", "");

    // Check if the amount is a valid integer
    int amount;
    Assert.IsTrue(int.TryParse(amountText, out amount), "The amount '{0}' is not a valid integer", amountText);
}

Dat is best wel veel gedoe voor de check van 1 regel tekst en dan zijn er nog genoeg cases die niet afgedekt worden: negatieve waarden worden niet als foutief gezien, wat gebeurt er als je ‘4 2’, ‘4.2’, ‘4e2’ of ‘4,2’ terugkrijgt? (dit vereist interne kennis over de int.TryParse method). En hoe ga je dit uitbreiden naar “Er zijn geen resultaten gevonden” en “Er is 1 resultaat gevonden”?

Het onderliggende probleem is: We proberen twee problemen tegelijkertijd op te lossen: Wat we willen checken en hoe we dat doen. Een betere strategie is om dat uit elkaar te trekken.

We kunnen dit oplossen door een regular expression te gebruiken:

public void CheckCorrectResultAmountMessage(string actualText)
{
    var pattern = "^Er zijn [0-9]+ resultaten gevonden$";
    Assert.IsTrue(Regex.IsMatch(actualText, pattern));
}

Nu kunnen de definitie (wat) en de implementatie (hoe) scheiden waarbij je het pattern op een andere plek bepaalt (in een config file, een database, Excel bestand of je testscenario) dan waar je het test. Als we dit bijvoorbeeld in een Feature file gebruiken dan bepalen we in de feature file de definitie (Wat we testen):

Scenario: There must be an amount displayed if there are results
Given I search for "ipod"
Then I can see the message "Er (zijn \d+ resultaten|is 1 resultaat) gevonden"

Scenario: A message should be shown when no results are found
Given I search for "sony walkman"
Then I can see the message "Er zijn geen resultaten gevonden"

en in de step definitie de implementatie (Hoe we dat doen):

[Then(@"I can see the message ""(.*)""")]
public void ThenICanSeeTheMessage(string expectedMessagePattern)
{
      var msg = MyFancyWebApp.GetMessage();
      Assert.IsTrue(Regex.IsMatch(msg, expectedMessagePattern));
}

Regular expressions is maar één gebied dat je helpt om definitie en implementatie te scheiden. Binnen applicatie development en dus ook test automatisering is Separation of Concerns een leidend principe dat je binnen een goede code basis veel terug zal zien komen. Samen met DRY (Don’t Repeat Yourself) en KISS (Keep It Simple Stupid) vormt dit de basis code principes waarmee je niet alleen jezelf, maar ook je team enorm helpt.

Dit bericht is geplaatst in Testautomatisering en getagd in design principles regular expressions

2 reacties op “Regular Expressions en Testautomatisering, twee problemen of juist een oplossing?”

  1. Mathijs schreef:

    Hoe maak je in je testdata onderscheid tussen een regular expression en een gewone tekst, in gewone tekst komen af en toe tekens voor die mis gaan bij een regex zoals haakjes of een plusteken?

  2. Bas Dam schreef:

    Goede vraag Mathijs. Als je SpecFlow gebruikt kan je een extra step aanmaken, eentje met “The message should be ‘something'” en een ander “The message should match ‘something'”. Dit zorgt vaak wel weer voor meer orchestratie in je step definities.

    Een andere manier die nog wel eens gebruikt wordt, vooral in ruwe check data zoals tabellen, is door een signaal karakter te gebruiken voor een regular expression. In het verleden gebruikte ik nog wel een het uitroepteken (dat komt nog uit de WinRunner tijd) maar tegenwoordig vaak een slash (/) voor en achter een pattern (zoals in bijvoorbeeld Java en JavaScript gebruikelijk is).

    Om nog even op de eerste methode terug te komen, in combinatie met Fluent Assertions en ArgumentTransformations kan je een generieke comparer aanmaken dat je de orchestratie uit handen neemt. Ik kan hier binnenkort wel eens iets over schrijven.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

TNW 2023

26/06/2023

Het Next Web (TNW) Conference is een jaarlijks evenement dat professionals uit de wereld van technologie, innovatie en ondernemerschap samenbrengt. Dit jaar vond TNW 2023 plaats in Amsterdam (eigenlijk Zaandam). Ik kreeg de kans om aanwezig te zijn en wil graag mijn ervaringen delen in deze blogpost. Het centrale thema van dit tweedaagse evenement was […]

06/06/2023

Work hard, play hard! Dat laatste hebben we vrijdag 2 juni letterlijk genomen. We zijn naar een museum geweest, het Nationaal Videogame Museum in het stadshart van Zoetermeer. Voor gamefanaten is dit echt een feestje. We kregen een interessante rondleiding waarbij we van alles te weten kwamen over de ontwikkeling van videogames, vanaf de vroege […]

testRigor

17/05/2023

Zijn we klaar voor AI-gestuurde testautomatiseringstools? Een blik op testRigor. Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van testRigor. […]

SRE – Site Reliability Engineering

19/04/2023

Tijdens de laatste maandelijkse kennismiddag van PerformanceArchitecten hebben we ons verdiept in het onderwerp SRE (Site Reliability Engineering). SRE combineert software engineering en operationele principes om grootschalige en complexe systemen te bouwen en beheren.   Ter introductie hebben we verschillende video’s bekeken waarin de definitie van SRE werd gegeven en het verschil tussen SRE en […]

NeoLoad RealBrowser

02/04/2023

Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag, waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van het RealBrowser “protocol” binnen het performancetesttool NeoLoad van Tricentis. Voor degenen […]

JMeter en Groovy

06/03/2023

Als je binnen JMeter iets wilt doen wat niet standaard in de tool zit, gebruik je plugins of ga je zelf code schrijven. In het geval dat je zelf code gaat schrijven, wordt aangeraden de groovy functie en JSR223 sampler te gebruiken. Ik wil hieronder graag bespreken welke mogelijkheden deze 2 opties je bieden, maar […]

Kennismiddag: ChatGPT

19/02/2023

Tijdens de maandelijkse kennismiddag op 14 februari bespraken collega’s de ontwikkelingen rondom ChatGPT, een tool die AI gegenereerde resultaten kan opleveren. Het werd onderzocht of ChatGPT ondersteuning kon bieden bij SEO en scripting. Hoewel de tool potentieel heeft, is verdere input en domeinkennis nog steeds nodig. ChatGPT is geen perfecte oplossing, maar kan wel handig zijn bij de uitvoering van werk. Het was een geslaagde middag en er wordt uitgekeken naar nieuwe onderwerpen voor de volgende kennismiddag.

16/09/2022

Performancetesten overdragen naar teams We zien bij onze klanten een duidelijke verschuiving van verantwoordelijkheden van centrale teams naar DevOps teams. “You build it, you run it” zorgt ervoor dat teams niet alleen zelf software moeten bouwen, testen en in productie brengen, maar ook verantwoordelijk zijn voor hoe de applicatie in productie draait. Eén van de […]

Azure Bicep

09/12/2021

Introductie Binnen de Azure omgeving is er veel mogelijk zoals bijvoorbeeld het runnen van pipelines en het creëren van infrastructuur. Maar om van deze mogelijkheden gebruik te kunnen maken zijn er uiteraard resources nodig. Deze resources zijn manueel via de portal aan te maken, maar ook door gebruik te maken van ARM (Azure Resource Manager) […]

Azure DevOps pipeline performance quality gate

31/10/2021

In mijn vorige blogs heb ik geschreven over Gatling simulaties in een executable jar en Azure DevOps pipeline met gatling. In het laatste blog had ik al aangegeven dat ik de performancetest onderdeel wilde laten zijn van de CD pipeline door het toevoegen van quality gates. Oftewel, ik wil dat de resultaten van de performance […]

Introductie in Pytest

07/04/2021

Inleiding Voor mijn huidige project ben ik bezig met het aspect kwaliteit in combinatie met Big Data. In zo’n modern project wordt hierbij ook AI gebruikt. Het inrichten van AI wordt vaak niet gedaan door ontwikkelaars, maar door data scientists die een omgeving nodig hebben wat het AI werk kan doen. De programmeertaal Python is […]

Website performance, belangrijker dan je denkt

27/11/2020

Inleiding We kennen het allemaal: je bent aan het surfen om iets te kopen. Duurt het langer dan 1 à 2 seconden dan haak je al snel af. Desondanks is performance is vaak onderbelicht in web-ontwikkeling. De nadruk ligt vaak op functionaliteit en minder op performance. Dat terwijl een slechte performance behoorlijke impact heeft op […]