Voel je zen met Pro­trac­tor

Met test­tools zo­als Pro­trac­tor hou je tijd over voor het tes­ten van in­te­res­san­te ed­ge-ca­ses.

Web Designer Magazine - - Inhoud - Rom­ke van der Meu­len

Met test­tools zo­als Pro­trac­tor hou je tijd over voor het tes­ten van in­te­res­san­te ed­ge-ca­ses.

Oké, ver­tel me eens of dit je be­kend voor­komt: je hebt een con­tact­for­mu­lier ge­bouwd en om te kij­ken of het werkt, open je het for­mu­lier in je brow­ser. Je vult al­le vel­den be­hal­ve het ver­plich­te veld ‘On­der­werp’ in en drukt op ‘Ver­stu­ren’ om te chec­ken of er een fout­mel­ding ver­schijnt. Dit con­tro­leer je re­gel­ma­tig tij­dens het ont­wik­ke­len en veel la­ter check je het nog een paar keer als je de code aan­past. Als je het niet ver­geet ten­min­ste. Kijk nu eens naar de vol­gen­de code:

de­scri­be('het con­tact­for­mu­lier', () => {

it('checkt dat het on­der­werp in­ge­vuld is', () => {

brow­ser.get('/con­tact');

const on­der­werp = ele­ment(by.css('in­put[na me=”on­der­werp”]')); const fout­mel­ding = ele­ment(by. id('on­der­werp-fout'));

ex­pect(on­der­werp.ge­tat­tri­bu­te('va­lue')). to­be(''); ex­pect(fout­mel­ding.is­pre­sent()). to­be(fal­se);

ele­ment(by.css('in­put[ty­pe=”sub­mit”]')). click(); ex­pect(fout­mel­ding.is­pre­sent()). to­be(true); ex­pect(fout­mel­ding.get­text()). to­be('on­der­werp is ver­plicht'); }); });

Stel je eens voor dat je de­ze code één keer schrijft en dat je daar­na de test zo vaak kunt uit­voe­ren als je wilt. Je hoeft al­leen maar één com­man­do te ge­ven. Dan opent het sys­teem au­to­ma­tisch je brow­ser, laadt de con­tact­pa­gi­na, klikt op de ver­stuur­knop en kijkt of de fout­mel­ding ver­schijnt. Zo niet, dan krijg je een fout­mel­ding, met het re­gel­num­mer waar in de test iets niet was zo­als ver­wacht. In een frac­tie van de tijd die het je kost om het­zelf­de met de hand te doen.

Pro­trac­tor is ont­wik­keld voor An­gu­lar­js, maar je kunt er al­le soor­ten we­bapps mee tes­ten

De code in dit voor­beeld is ge­schre­ven voor Prot­ac­tor. Pro­trac­tor is een test­tool die oor­spron­ke­lijk ont­wik­keld was voor An­gu­lar­js, maar ge­schikt is voor al­le soor­ten we­bapps. Het is ge­bouwd op Se­le­ni­um, maar met een wat meer toe­gan­ke­lij­ke API en vrien­de­lij­ke­re do­cu­men­ta­tie. De in­stal­la­tie is en­kel een kwes­tie van een paar Npm-mo­du­les in­stal­le­ren en wat con­fi­gu­ra­tie schrij­ven. Er staan pri­ma voor­beel­den in de Pro­trac­tor-do­cu­men­ta­tie op pro­trac­tor­test.org.

Wat ik nou zo mooi vind aan de­ze code, is dat je di­rect kunt le­zen wat er pre­cies ge­beurt. Je zou de­ze test met de hand kun­nen na­doen, wat heel han­dig is als je een test moet de­bug­gen. Ge­luk­kig komt dat niet vaak voor.

En dat is al­leen nog maar als je de Pro­trac­tor API di­rect in je test aan­roept. Om het nog mooi­er te ma­ken, kun je er zelf een ex­tra laag code tus­sen schrij­ven. De Pro­trac­tor-do­cu­men­ta­tie noemt zo’n laag ‘Pa­ge Ob­jects’. Hie­rin kun je im­ple­men­ta­tie­de­tails weg­stop­pen zo­als se­lec­tors voor het vin­den van elementen in je UI, of ver­schil­len­de va­ri­a­ties van de URL waar­mee de pa­gi­na ge­la­den kan wor­den. Het voor­deel van zo’n tus­sen­laag is dat de test zelf nog scho­ner, be­ter lees­baar en mak­ke­lij­ker te on­der­hou­den wordt. Bij Ve­vi­da heb­ben we hier in­tus­sen aar­dig wat er­va­ring mee en we heb­ben wat tips ge­pu­bli­ceerd op on­ze web­si­te.

Nu het tes­ten toch al zo veel mak­ke­lij­ker is, kun je ook wat tijd in­ves­te­ren in de in­te­res­san­te ed­ge­ca­ses die je met de hand bij­na nooit test. Wat ge­beurt er bij­voor­beeld als het in­stu­ren van je for­mu­lier mis­lukt? Gaat de he­le pa­gi­na stuk? Of ver­schijnt er een be­hulp­za­me fout­mel­ding? Een test hier­voor is zo ge­schre­ven en als die een­maal slaagt, kun je er rus­tig van uit­gaan dat alles werkt zo­als je wilt.

Er ge­beurt iets met je wan­neer je het me­ren­deel van je web­si­te op de­ze ma­nier test. Het is een ge­voel waar­over ik eer­der las in ver­ha­len van back-end pro­gram­meurs die goe­de dek­king had­den ge­haald met hun unit-tests. Het is een ge­voel van zelf­ver­ze­kerd­heid. Van niet meer hoe­ven aar­ze­len voor in­grij­pen­de wij­zi­gin­gen.

Soms heb je na­me­lijk van die gro­te, in­grij­pen­de aan­pas­sin­gen waar­van je weet dat ze je co­de­ba­se op de lan­ge ter­mijn veel be­ter ma­ken, maar waar je nooit aan wilt be­gin­nen om­dat je ge­woon wéét dat er in de tus­sen­tijd din­gen stuk gaan. Her­ken je dat? Ik heb net een van die gro­te wij­zi­gin­gen ge­daan. En ik maak­te me geen en­ke­le zor­gen. Want na el­ke aan­pas­sing kon ik ge­woon de Pro­trac­tor­tests op­nieuw draai­en en zag ik di­rect dat er niets stuk was. Of als er wel iets stuk was, dan wist ik di­rect dat dat door mijn laat­ste wij­zi­ging kwam en kon ik kij­ken waar­om het daar stuk van ging.

Ja, het kost je in het be­gin wat ex­tra tijd om Pro­trac­tor in te stel­len en je tests net­jes op te schrij­ven. Doe het toch. Niet al­leen om­dat het je uit­ein­de­lijk al­leen maar meer tijd op­le­vert. Doe het voor je ge­moeds­rust.

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.