Er is iets vreemds in Selector land

 

Dit hele verhaal begon omdat ik keek naar een stukje door AI gegenereerde Playwright code. En onmiddellijk voelde “Hier klopt iets niet.” Maar toen ik hier later met een collega over sprak, merkte ik dat ik met mijn uitleg niet veel verder wist te komen dan “Dat doe je zo niet”. Niet dat de code niet zou werken, in de meeste gevallen wel. Maar als de code wel werkt, waarom voelde de code dan toch verkeerd?

Wat ik in de Playwright code miste was veel GetBy… selectors. En dat terwijl er wel degelijk selectors waren op basis van tekst en rol. GetByRole, GetByText, GetByLabel, een van het eerste wat je leert bij Playwright. Aangeleerd door cursussen, gebruikt in voorbeelden, maar ik vraag me toch af: hoeveel mensen weten waarom?

Daarnaast viel mij nog iets anders op: de door AI gegenereerde code deed me ook aan iets denken. Aan de manier waarop ik met Selenium een selector maakte op tekst en rol. Dat deed mij beseffen: ik ben onbewust steeds meer overgeschakeld van de standaard manier van selectors binnen Selenium naar de standaard manier van selectors in Playwright. Gewoon, omdat de cursus dat zei en mijn collega’s dat al deden. En dat voor een persoon, die een sterk voorstander is van beargumenteerde keuze.

Wat de door AI gegenereerde code betreft zijn er meerdere mogelijke verklaringen. Het zou kunnen dat oudere voorbeelden een rol spelen, uit een tijd waarin Playwright nog minder GetBy… selectors had. Daarnaast lijkt de code aan te sluiten bij selectiemethoden die ook uit b.v. Selenium bekend zijn. Dat zou kunnen verklaren waarom de code afwijkt van de huidige standaard, maar wel correct is.

Wat betreft mijn eigen onbewuste switch? Ik had geleerd dat tekst te vaak wijzigt om te gebruiken. En ID of Name zou stabieler zijn. Maar in de praktijk heb ik hier nooit zoveel verschil in gemerkt. Het ene moment blijft de naam eeuwig staan, maar wordt constant geëxperimenteerd met de wijze van tonen en/of invoer, waardoor vaak ook ID of Name wijzigen. De andere keer blijft de wijze van invoer steeds gelijk, maar probeert men steeds andere varianten van tekst uit. Maar in de praktijk wijzigen beide eigenlijk niet zo vaak. En het grootste voordeel van een GetByText ten opzichte van een By.Id heb ik eigenlijk nergens gelezen: ik hoef het element meestal niet in de HTML-code op te zoeken om een selector te kunnen schrijven. Tekst en role kan ik namelijk altijd zien. Name en id moet ik bewust zoeken.

Toch blijf ik het wat vreemd vinden. Door middel van cursussen en voorbeeldcodes worden ons voorkeuren aangeleerd. Voorkeuren waardoor het merendeel van ons waarschijnlijk onmiddellijk denkt “Hier klopt iets niet”, als code hiervan afwijkt. Zonder dat het fout is, zonder dat we weten waarom. De belangrijkste reden, die wordt gegeven voor een selector voorkeur is stabiliteit. Maar dit is vooral voor de door de tool beter ondersteunde selectors t.o.v. css of xpath selectors. Informatie waarom Selenium geen expliciete By.text() aanbiedt (waardoor tekstselectie via vaak XPath loopt) en waarom Playwright geen getById() heeft (waardoor id-selectie vaak via CSS blijft lopen), kon ik moeilijk terugvinden.

Het voelt een beetje als “Wij bepalen voor jou wat beter is”. Maar ach, gebeurt dat uiteindelijk niet meer in de wereld van testen en ICT? Waarin vele van ons doen wat ons aangeleerd is, zonder te bedenken waarom? Zonder soms zelfs te weten dat er andere opties zijn?

Voor testautomatisering draait het er uiteindelijk om dat je code goed tegen wijzigingen kan. Naar mijn mening, ondanks alle voorkeuren van testframeworks, is dat toch iets wat project afhankelijk is. Zoals ik eerder schreef wordt bij het ene project meer gespeeld met de tekst en bij de andere met de elementen. Dus de meest stabiele testautomatiseringscode is code die daar rekening mee houdt. Ongeacht of dit de aangeraden wijze is of niet.

Maar het was een buitengewone interessante ontdekkingstocht. Hopelijk was het net zo interessant om te lezen.