Eerder schreven we al een blog over Playwright en de voordelen van deze tool voor browserautomatisering. Collega Diana werkte bij een opdrachtgever met de .NET-variant van Playwright in combinatie met Cucumber. Hoewel het werken met Playwright haar goed beviel, werd haar nieuwsgierigheid gewekt naar de TypeScript-variant. TypeScript is immers de taal waarin nieuwe Playwright-features als eerste beschikbaar komen. Sommige functionaliteiten, zoals de UI mode waarmee je stap voor stap kunt zien wat er tijdens een test gebeurt, zijn zelfs exclusief beschikbaar in TypeScript. Haar nieuwsgierigheid leidde tot het opzetten van een eigen oefenomgeving. Hoe heeft Diana dit aangepakt? En welke lessen nam zij mee uit dit leerproces?
Een eigen leerproject in TypeScript
Vanuit mijn nieuwsgierigheid ben ik gestart met een persoonlijk leerproject: een Playwright-repo in TypeScript, gekoppeld aan het Bartosz-testobject. In eerste instantie nam ik mijn bestaande werkwijze mee en bouwde ik de repo op met Playwright in Typescript, gecombineerd met Cucumber. Dat voelde als een logische stap, omdat ik Playwright vaker op deze manier heb gebruikt. Een gesprek met collega Dyon zette mij aan het denken, hij daagde mij uit om de repo zonder Cucumber op te zetten. Het argument hiervoor? Playwright biedt van zichzelf al voldoende structuur en leesbaarheid. Een extra abstractielaag voegt niet per definitie waarde toe en kan tests juist complexer maken of de uitvoering vertragen. Dit verschil wilde ik zelf ervaren en ik besloot Cucumber uit de repo te halen en de opzet opnieuw te evalueren.
Leren door los te laten
Het verwijderen van de Cucumber-laag dwong mij opnieuw na te denken over de opzet van mijn tests. Hoe zorg je voor leesbaarheid zonder Gherkin? En hoe blijven scenario’s begrijpelijk voor anderen? Deze keuzes hebben direct invloed op de kwaliteit en onderhoudbaarheid van de repo. Tijdens dit proces ontdekte ik dat TypeScript volop mogelijkheden biedt om tests beschrijvend en goed leesbaar te maken. Leesbaarheid begint niet bij een extra framework of abstractielaag, maar bij bewuste keuzes in de code zelf. Dat was voor mij een belangrijk inzicht. Deze manier van werken laat bovendien zien hoe krachtig samen leren kan zijn. Door te sparren met collega’s ging ik experimenteren, durfde ik fouten te maken en leerde ik daarvan. Deze werkwijze sluit naadloos aan bij het gedachtegoed rondom de ontwikkeling van de moderne tester: leren door te doen, in de praktijk, en van de mensen om je heen.
Samen leren in de praktijk
Al snel merkte ik dat dit project niet alleen voor mij interessant was. Binnen Bartosz zijn er meerdere collega’s, waaronder trainees, die graag oefenen met nieuwe tools. Het project werd gezamenlijk opgepakt en iedere deelnemer bracht een eigen perspectief mee. Hoe hebben we dit aangepakt? Door ieder een ander deel van het testobject te automatiseren en vervolgens elkaars werk te reviewen. Door het stellen van kritische vragen, bouwden we onze kennis op en werden de tests steeds leesbaarder en de code herbruikbaarder. Het project groeide daarmee uit tot een gezamenlijke leeromgeving. Om collega’s actief te betrekken, heb ik tijdens een maandmeeting een Booszt-sessie gehouden over de repo. Het doel van deze sessie was om collega’s te informeren over de oefenomgeving én om hen te enthousiasmeren om er zelf mee aan de slag te gaan.
