Automatische Tests in Magento

Iedere webshop voert onderhoud en updates uit, waardoor de code van de shop wordt gewijzigd. Na wijzigingen aan de code van de shop test je vaak of de webshop nog naar behoren werkt. Dit kan handmatig, maar ook automatisch. Door handmatige checks te vervangen met automatische tests, worden fouten eerder gespot en weet de developer exact waar het probleem zich in de code voordoet en kan hij deze sneller en op juiste wijze oplossen. Dit bespaart niet alleen tijd, maar bovendien ook geld.

Testautomatisering Magento

In tegenstelling tot Magento 1, brengt Magento 2 zijn veiligheid fixes uit in de vorm van een security update. Deze updates brengt Magento ieder kwartaal uit. Door te updaten zorgt je ervoor dat je shop veilig is en aan de laatste veiligheidsupdates voldoet. Toch kleeft er een nadeel aan de nieuwe manier van werken.

Want een update brengt wijzigingen aan in de code van jouw webshop. Door wijzigingen aan de code kan het voorkomen dat er bugs in enkele functies of third-party modules voorkomen. Toch is een update nodig, zodat jouw webshop veilig is en blijft voor aanvallen van buitenaf.

Na het uitvoeren van een update wordt door middel van handmatige Quality Assurance check de webshop nagelopen en worden fouten zo veel mogelijk uitgesloten. Dit is een tijdrovende taak en het geeft geen garantie tot een volledige foutloze inspectie. Fouten in de code zijn met handmatige checks lastig op te sporen.

De oplossing: automatisch testen.

Door de handmatige checks te vervangen met automatische tests, worden fouten eerder gespot en weet de developer exact waar het probleem zich in de code voordoet en kan hij deze sneller en op juiste wijze oplossen. Dit bespaart niet alleen tijd, maar bovendien ook geld.

Magento 2 is een geweldig ecommerce platform met oneindig veel mogelijkheden in de vorm van modules en features. Bij het ontwikkelen van een Magento webshop wordt aan de hand van de code de webshop gerealiseerd. Zo worden de modules en features geïntegreerd middels de op dat moment bestaande manier van werken, regels, wetten en kennis. Toekomstige updates of nieuwe modules en/of features, kunnen invloed hebben op de bestaande code van de shop. Developers kunnen rekening houden met eventuele, toekomstige, wijzigingen aan de code door hier (in de code zelf) automatische tests aan toe te voegen. Hierbij wordt er rekening mee gehouden of de functie die gemaakt is blijft werken na code wijzigingen aan de shop. Er zijn verschillende soorten testen die hiervoor gebruikt worden. Deze lopen idealiter via de ‘Testing Piramide’.

Testing Pyramid vs. Icecream Cone

De test piramide geeft in drie lagen de ideale verhoudingen van automatische testen weer. De uiteindelijke verhoudingen zullen per systeem verschillen, maar in de praktijk houdt het in dat je veel meer Unit tests nodig hebt dan End-To-End (E2E) tests. Deze termen klinken nu wellicht nog onbekend, maar worden straks verder toegelicht.

testin12
De Testing Pyramide vs De Icecream Cone

Bij handmatige Quality Assurance checks is het mogelijk dat fouten te laat of zelfs helemaal niet worden opgemerkt. Dit staat bekend als het ‘Icecream Cone’ model. Bij dit model voer je handmatige testen uit die de functionaliteit van de webshop test en af en toe voer je E2E tests uit. Deze testen nemen veel tijd in beslag om uit te voeren en te maken.

Wanneer je gebruikt maakt van E2E test gebruik je de Grafisch User Interface (GUI). Met de Grafische User Interface bij Magento, test je het frontend van de webshop. Je test dan bijvoorbeeld of een knop nog naar de juiste pagina gaat of dat het menu zich opent wanneer je met je muis over een menu item gaat.

Met de testing piramide draai je dit model om, zodat je door relatief kleine aanpassingen vele tests op de achtergrond kan laten lopen en fouten in een vroeg stadium ontdekt worden.

Voordelen Testing Pyramid

  • Snelle implementatie door het uitvoeren van kleine tests
  • Pro-actief fouten opsporen
  • Wijzigingen worden niet naar live gezet als er een fout in een van de tests zit
  • Snellere foutopsporing, zorgt voor een snellere oplossing
  • Handmatige tests kunnen worden ingekort, wat tijd en geld bespaart
  • Automatische tests besparen kosten t.o.v. werkuren

De test lagen van de piramide

Er zijn verschillende soorten testen te vinden in de piramide, maar in de basis kun je ze onderverdelen in drie soorten automatische testen: Unit tests, Integration tests en E2E tests. Hoe hoger je in de piramide komt, hoe langer het duurt om een test te ontwikkelen. E2E tests komen dan ook minder vaak voor, omdat een groot deel opgevangen kan worden door testen uit de andere lagen.

Unit test:

Unit tests zijn kleine testen die over een stukje code gaan. Dit is een simpel stukje op zichzelf staande code, die geen connectie heeft met andere codes van de shop. Je test dus alleen een stukje code van een functie, zodat je bij een fout direct weet in welk stukje code dit zit. Je gebruikt hierbij geen data uit een database, alles gaat op basis van de code. Een voorbeeld hiervan is een percentage calculator.

Percentage calculator: 1 = 100%. Zet je het getal 0,05 in de calculator, dan moet er 5% uitkomen. Deze test controleert dus of een getal wordt omgezet naar een percentage.

Unit tests zijn klein en je kunt heel veel diverse Unit tests hebben lopen. Het uitvoeren van deze testen duurt niet lang. Zo kun je wel 10.000 Unit tests tegelijkertijd hebben lopen die minder dan 5 minuten in beslag nemen. Dit soort testen gebruiken wij bijvoorbeeld wanneer we een eigen module ontwikkelen. Voor Magento functionaliteiten werken wij met het meeste met Integration tests, waarbij we gebruik maken van de database. Een Unit test kan namelijk prima werken, maar in combinatie met een database bijvoorbeeld niet.

r 519301 QxQcw
Een geslaagde Unit test, maar niet werkend met andere onderdelen

Integration test:

Je gebruikt bij Integration tests niet alleen de code, zoals bij een Unit test, je test een systeem, zoals Magento, in zijn geheel met database. Dit doe je zonder de Grafische User Interface (GUI), zoals het frontend van de shop. Omdat je bij deze testen het frontend niet gebruikt, zijn deze testen sneller te ontwikkelen en minder onderhoudsgevoelig. Hoewel we het grafische deel van het frontend niet gebruiken tijden het testen, kunnen we wel testen maken die de code van het frontend gebruiken. Zo kun je wel kijken wat er op de broncode van de pagina staat, maar niet op een button klikken. Je kunt in de code dus wel zien of bepaalde elementen aanwezig zijn op het frontend.

Voorbeelden van Integration tests

  • Test het aanpassen van een product title op storeview niveau. Wijzigt de product title voor alle stores, dan zit er een fout in de code. Wijzigt alleen de product title voor de gewenste store, dan is de test geslaagd.
  • Testen van de checkout. Je kunt testen of een order geplaatst kan worden of dat een bepaalde betaalmethode werkt in combinatie met een verzendmethode. Werkt het niet, dan weet je dit omdat de order niet geplaatst kan worden.
  • Test het toevoegen van een comment bij een order. We maken een order aan met een comment erbij, vervolgens halen we de order op en checken we of we ook de comment op kunnen halen. Je test of deze functie blijft werken, ook na diverse wijzigingen aan de shop.

Zo kun je ook testen of een product wordt verwijderd, een product een prijs en/of sale prijs heeft, je kunt inloggen, zien of er API calls worden gemaakt, er cronjobs lopen, er wijzigingen in de database worden gemaakt, etc.

Doordat de Magento database gebruikt wordt bij Unit tests, zijn de mogelijkheden oneindig. Je kunt alle onderdelen van Magento testen. In de meeste gevallen gebruik je een lege database met dummy producten, omdat de data van de live database niet nodig is voor deze tests. Het voordeel van Integration tests is dat ze snel te maken zijn en er complexe testen gemaakt kunnen worden.

tenor-1
Twee geslaagde Unit tests, maar geen geslaagde Integration test

Voor belangrijke onderdelen van een webshop die je stabiel wilt laten lopen, worden Integration tests ingezet. Bij wijzigingen aan de code gaan automatisch alle testen die zijn ingesteld lopen. Wijzigingen aan de database van Magento hebben geen invloed op de code en triggeren deze tests niet. Op deze manier weet je of code wijzigingen aan de shop ook invloed hebben op bepaalde onderdelen uit de Integration test. Het kan wel eens voorkomen dat een nieuwe module invloed heeft op een andere functie die al een tijdje in gebruik is. Om deze reden zijn Integration tests een goede toevoeging voor het behoud van een stabiele webshop.

Bij het live zetten van code wijzigingen voor de webshop, lopen onze tests via Travis. Dit systeem wordt gebruikt om projecten, die via GitHub lopen, te bouwen en te testen. Travis controleert bij het live zetten van releases of de code naar de live omgeving gezet mag worden. Als een test niet door de keuring komt, wordt de nieuwe versie niet live gezet. Zo voorkom je dat jouw webshop onnodig live gaat met fouten die daarna nog opgelost moeten worden. Deze fouten worden eerst opgelost en gaan na goedkeuring alsnog naar live. Hiermee verbeter je de ervaring en de stabiliteit van de webshop aanzienlijk.

travisbuild
Travis build bij het live zetten van wijzigingen

In sommige gevallen is het ook mogelijk om de tests dagelijks te laten lopen, in plaats van alleen na een wijziging van de code. Bijvoorbeeld bij een functie die gekoppeld is aan een derde systeem. Het kan namelijk zo zijn dat er wijzigingen plaats vinden aan het andere systeem buiten Magento om. Denk hierbij bijvoorbeeld aan een voorraadkoppeling. Je test hierbij of de API call van de voorraad wordt verstuurd en of dit wordt gewijzigd in Magento.

Integration tests klinken nu wel als een van de beste automatische test opties voor Magento, toch is er een kleine kanttekening aan deze tests. Hoewel de code goedgekeurd kan worden, kan het zijn dat er alsnog een fout in zit. Dit kan namelijk zitten in het frontend. Een functionaliteit kan dan prima werken, maar de styling van deze functionaliteit hoeft niet te kloppen. Integrations tests, testen niet hoe de styling eruit ziet. Verder kan Javascript niet worden getest met Integration tests, wat bij moderne webshops vaak voorkomt in de checkout. Voor Javascript heb je E2E tests nodig.

travistestfailed
De Unit tests werken, maar de Integration test niet

Live voorbeeld Integration Test
Als Core Partner van Vue Storefront, helpen wij mee aan het verbeteren van de Vue Storefront open-source code. Zo hebben wij een sitemap voor Magento 2 in combinatie met Vue Storefront ontwikkeld. Hiervoor hebben wij een Integration test gemaakt die de stabiliteit van de module bewaakt.

Bij een wijziging aan de code wordt het genereren van de sitemap getest. Dit loopt als volgt:

  • 1. Er wordt een lege Magento store opgezet met deze module
  • 2. Er wordt gecheckt of de module aanstaat in Magento
  • 3. Er worden 4 dummy producten aangemaakt in Magento
  • 4. Daarna wordt de sitemap gegenereerd via de module
  • 5. De test checkt of de 4 dummy producten in de sitemap staan
  • 6. De test wordt succesvol afgerond of toont een fout in de code als een van de producten niet in de sitemap staan.

    livevoorbeeld

Bovenstaande test kun je laten lopen voor meerdere Magento of Php versies

Voordelen Integration tests:
Snel opgezet Hoge waarde voor de stabiliteit Bij fouten in de test wordt er geen code live gezet Meerdere tests mogelijk voor diverse functionaliteiten Spot de fout direct en bespaart tijd Mogelijk om alle Magento functies te testen door gebruik van database

E2E/GUI test:

End-to-End (E2E) tests worden ook wel Graphic User Interface (GUI) tests genoemd. Je test hiermee wijzigingen aan het hele systeem inclusief het frontend. Zo kun je stappen simuleren die de eindgebruiker ook zal nemen. E2E tests worden dan ook het meest gebruikt om de gebruiker na te bootsen op de shop.

Voorbeeld van een E2E test

  • 1. Chrome versie 10 aanzetten
  • 2. Klik op een categorie
  • 3. Klik op een product
  • 4. Klik op de ‘add to cart’ button
  • 5. Check of er rechts bovenin een mini cart zichtbaar is met daarin het toegevoegde product.

Het mooie aan E2E tests is dat je hiermee het frontend en daarmee de styling van de webshop kan testen. Je kunt het design daarmee ook in verschillende browsers of devices testen. Bijvoorbeeld het testen van de checkout op een Android en Iphone device.

E2E testen zijn complexere testen en worden in verhouding niet vaak gebruikt, omdat ze relatief veel tijd in beslag nemen om te maken en langzaam zijn in de uitvoer. Je gebruikt E2E testen alleen om de gebruikersinterface te testen en niet om de business logica te testen. Doordat de database van Magento gekoppeld is en het frontend wordt getest, worden ze bij iedere database wijziging gedraaid. Doordat de test een simulatie is van diverse onderdelen (backend en frontend), duurt de uitvoer langer dan de andere twee testen. E2E testen worden dan ook vaak tot het minimum beperkt.

Meer weten over automatische testen?

Wij helpen je graag verder met de stabiliteit van jouw webshop. Wil je graag aan de slag met Integration tests in Magento, dan helpen we jou daar graag bij. Neem contact op met ons om de mogelijkheden voor jouw webshop door te nemen.