Protractor is een tool die automatisch kan testen of jouw zelfgebouwde website pagina / onderdelen zich precies zo gedragen als de bedoeling is, zodat je dat niet meer met de hand hoeft te doen. In dit artikel vertelt onze ontwikkelaar Romke je meer over deze handige tool, en waarom het een goed idee is om uitgebreide tests voor jouw website te schrijven.

 


 

Oké, vertel me eens of dit je bekend voorkomt: je hebt zelf een contactformulier gebouwd, en om te kijken of het werkt open je het formulier in je browser. Je drukt op “Versturen” en checkt of er een foutmelding verschijnt omdat het verplichte onderwerp-veld niet ingevuld was. Dit check je tijdens het ontwikkelen regelmatig, en veel later als je de code aanpast check je het nog een paar keer. Als je het niet vergeet tenminste.

Kijk nu hier eens naar:

describe('Het contactformulier', () => {

  it('checkt dat het onderwerp ingevuld is', () => {
    browser.get('/contact');

    const onderwerp = element(by.css('input[name="onderwerp"]'));
    const foutmelding = element(by.id('onderwerp-fout'));

    expect(onderwerp.getAttribute('value')).toBe('');
    expect(foutmelding.isPresent()).toBe(false);

    element(by.css('input[type="submit"]')).click();
    expect(foutmelding.isPresent()).toBe(true);
    expect(foutmelding.getText()).toBe('Onderwerp is verplicht');
  });
});

Stel je eens voor dat je deze code één keer schrijft, en dat je de test daarna kunt uitvoeren zo vaak je wilt. Je hoeft alleen maar een commando te geven. Dan opent het systeem automatisch je browser, laadt de contactpagina, klikt op de verstuurknop, en kijkt of de foutmelding verschijnt. Zo niet, dan krijg je een foutmelding, met het regelnummer waar in de test iets niet was zoals verwacht. In een fractie van de tijd dat het je kost om hetzelfde met de hand te doen.

De code in dit voorbeeld is geschreven voor Protactor. Protractor is een test tool, origineel ontwikkeld voor AngularJS, maar geschikt voor alle soorten webapps. Het is gebouwd op Selenium, maar met een wat toegankelijkere API en vriendelijkere documentatie. Installatie is enkel een kwestie van een paar NPM-modules installeren en wat configuratie schrijven. Er staan prima voorbeelden in de Protractor documentatie op protractortest.org.

Wat ik nou zo mooi vind aan bovenstaande code is dat je direct kunt lezen wat er precies gebeurt. Je zou deze test met de hand kunnen nadoen (en dat is heel handig als je een test moet debuggen, wat gelukkig niet vaak voorkomt).

En dat is alleen nog maar als je in je test direct de Protractor API aanroept. Om het nog mooier te maken kun je zelf een extra laag code ertussen schrijven. De Protractor documentatie noemt zo’n laag “Page Objects”. Hier kun je implementatiedetails in wegstoppen, zoals bijvoorbeeld selectors voor het vinden van elementen in je UI, of verschillende variaties van de URL waarmee de pagina geladen kan worden. Het voordeel van zo’n tussenlaag is dat de test zelf nog schoner en beter leesbaar wordt, en makkelijker te onderhouden. Bij Vevida hebben we hier intussen aardig wat ervaring mee, en we hebben wat tips gepubliceerd op onze website.

Nu het testen toch al zo veel makkelijker is, kun je ook wat tijd investeren in de interessante edge-cases die je met de hand bijna nooit test. Wat gebeurt er bijvoorbeeld als het insturen van je formulier mislukt? Gaat de hele pagina stuk? Of verschijnt er een behulpzame foutmelding? Een test hiervoor is zo geschreven, en als die eenmaal slaagt kun je er rustig van uit gaan dat alles werkt zoals je wilt.

Er gebeurt iets met je wanneer je het merendeel van je website op deze manier test. Het is een gevoel waarover ik eerder las in verhalen van backend programmeurs die goede dekking hadden gehaald met hun unit-tests. Het is een gevoel van zelfverzekerdheid. Van niet meer hoeven aarzelen voor ingrijpende wijzigingen.

Soms heb je namelijk van die grote, ingrijpende aanpassingen waarvan je weet dat ze je codebase op de lange termijn veel beter maken, maar waar je nooit aan wilt beginnen omdat je gewoon wéét dat er in de tussentijd dingen stuk gaan. Herken je dat? Ik heb net een van die grote wijzigingen gedaan. En ik maakte me geen enkele zorgen. Want na elke aanpassing kon ik gewoon de Protractor tests opnieuw draaien en zag ik direct dat er niets stuk was. Of als er wel iets stuk was, dan wist ik direct dat dat door mijn laatste wijziging kwam en kon ik kijken waarom het daar stuk van ging.

Ja, het kost je in het begin wat extra tijd om Protractor in te stellen en je tests netjes op te schrijven. Doe het toch. Niet alleen omdat het je uiteindelijk alleen maar meer tijd oplevert. Doe het voor je gemoedsrust.

Over de auteur

Dit artikel is geschreven door onze ontwikkelaar Romke van der Meulen. Als je meer van dit soort artikelen wilt lezen kun je zijn (Engelstalige) blog bekijken.

 

Gerelateerde artikelen