Het schrijven van end-to-end specificaties is altijd interessant en leuk. Om nog maar te zwijgen, het is noodzakelijk om het proces van code-refactoring veiliger te maken – ze werken als foutdetectoren. Vaak zijn die scenario’s de enige functiedocumentatie in de codebase.
We hebben echter ook te maken met ongemak: soms duurt het te lang voordat we voldoende gegevens hebben ingesteld, evenals CSS-afhankelijkheden en talloze wijzigingen in CSS en HTML. Evenzo is het misschien niet zo eenvoudig om in één keer een leesbare en onderhoudbare code te schrijven.
End-to-end testen met AngularJS: tips en trucs
Gelukkig kunnen die problemen worden opgelost. Vandaag willen we u vertellen over een aantal eenvoudige technieken die u kunt gebruiken om de hierboven genoemde aspecten te beheren. Aanvankelijk waren die scenario’s geschreven voor Protractor, maar ze passen perfect bij elk ander testraamwerk waarmee u wilt werken.
Bekijk hieronder een duidelijk voorbeeld van opmaak met gerelateerde specificaties. Laten we nu proberen die te upgraden.
Speciale eigenschappen afzonderlijk testen
Ontwikkelaars werken vaak afzonderlijk met CSS- of HTML- en AngularJS-componenten. Als gevolg hiervan treden er veel specificatie-afhankelijkheden op tijdens het maken van opmaakwijzigingen. Dit is inderdaad een groot probleem waar bijna elk team mee te maken heeft. Wanneer een front-end engineer bijvoorbeeld de naam van de utility-klasse wijzigt of een andere klasse gebruikt in overeenstemming met CSS-wijzigingen, kan hij per ongeluk specificaties breken.
Natuurlijk kun je dit probleem oplossen door constante controle van end-to-end specs selectors, maar dit is niet echt handig – je moet elke aangebrachte markup-wijziging bekijken. Een andere manier is om semantiek van een stabiel model toe te passen op elk onderdeel. Maar ook dit vraagt te veel inspanningen. Naar onze mening is de oplossing om een specifiek attribuut alleen door een testraamwerk te laten gebruiken:
Welnu, die attributen rond de opmaak lijken misschien verouderd. Aan de andere kant brengt deze techniek ons een aantal voordelen. Laten we eens kijken:
- elk afzonderlijk element heeft een specifieke en betekenisvolle naam;
- het wordt gemakkelijker en veiliger om opmaakwijzigingen toe te passen;
- specificaties zijn niet langer afhankelijk van CSS-wijzigingen.
Pagina- en componentobjecten beheren
Pagina-objecten worden vaak gebruikt bij het schrijven van end-to-end-tests. Hierdoor worden specificatievoorbeelden veel handiger om te hergebruiken en te onderhouden. Bekijk hieronder hoe eenvoudige pagina-objecten worden gedefinieerd voor specificaties:
Nu zien testvoorbeelden er veel schoner uit zonder CSS-selectors.
Een decorateur wordt nu gedefinieerd als:
Als resultaat hebben we volledig herbruikbare specificatievoorbeelden die niet afhankelijk zijn van CSS-wijzigingen, evenals een functionele DSL die klassen van pagina- of componentobjecten definieert. U weet nu dus hoe u uw end-to-end testen kunt vergemakkelijken.
Artikel is geschreven door Ruby on Rails-ontwikkelaars van Rails Ware company – outsourcingbedrijf gevestigd in Oekraïne, de VS en Polen.