Wanneer het gaat over OutSystems, denk je meteen aan Low Code, maar zelfs binnen Low Code blijft ontwikkelen een kernactiviteit. Dat omvat niet alleen het schrijven van code en het analyseren van vereisten, maar ook het cruciale aspect van testen.
Dit kan op verschillende manieren.
- Je test je eigen code.
- Een andere developer test jouw code
- Een tester test jouw code.
Vaak wordt dit als voldoende testen gezien in een project. Maar nu is de vraag hoe waarborg je dat de code die toen is gemaakt, nog steeds blijft werken in de toekomst?
Gelukkig heeft OutSystems daar iets voor gemaakt, het BDDFramework (Behavior Driven Development Framework).
Wat is een BDDFramework eigenlijk? In deze blog gaan we duidelijk maken wat een BDDFramework is en hoe je hiermee beter kan waarborgen dat je code correct blijft werken in de toekomst.
Je code kan omvallen door verschillende oorzaken. Bijvoorbeeld door zelfgemaakte wijzigingen, maar ook door patches met nieuwe versies, of door wijzigingen in “objecten” van anderen die je gebruikt en afhankelijk bent.
Wat is en kun je met het BDDFramework van OutSystems?
Het BDDFramework van OutSystems geeft je de mogelijk om test-driven te developen. Er kunnen tests gemaakt worden op acties of processen binnen die valideren of ze ook daadwerkelijk doen wat ze zouden moeten doen.
Wat hebben we allemaal nodig om een actie te gaan testen?
- We moeten scenario’s bedenken welke voor kunnen komen.
- Kijken welke gegevens we nodig hebben voor deze actie die we gaan testen.
- Wat verwachten we dat we terugkrijgen als we de actie gaan aanroepen.
- Welke gegevens moeten na de test weer verwijderd worden om corrupte data te voorkomen in de database.
- Scenario: Hier geven we aan welke test er precies getest wordt.
- Scenario Description: Je kunt hier nog een aangeven wat er precies getest gaat worden tijdens deze test.
- Setup: Moet er nog iets gedaan worden voor dat de actie wordt aangeroepen. (Denk aan records aanmaken)
- Given: De gegevens die worden gebruikt tijdens deze BDD (Welke gegevens zijn er gebruikt tijdens deze test)
- When: Welke actie wordt er precies getest.
- Then: Hier gaan we kijken als de verwachte uitkomst gelijk is aan de daadwerkelijke uitkomst. Dit kan op verschillende manieren die BDDFrameworkje standaard aanbiedt.
- Assert(Value): Wat verwacht je en wat heb je daadwerkelijk gekregen. Met Value kun je ook nog eens aangeven als hij fout gaat wat hij dan aan extra informatie moet tonen.
- AssertFalse: Je verwacht dat hij als output een boolean, False
- AssertTrue: Je verwacht dat hij als output een boolean, Trueteruggeeft,
- Teardown: Hier kunnen de gegevens worden verwijderd die zijn aangemaakt tijdens deze BDD Dit doe je om te voorkomen dat er corrupte data in je omgeving gaat ontstaan.
Nu weten we hoe we een BDD test op kunnen zetten maar hoe kun je hem het beste gebruiken.
Om te voorkomen dat je voor elke scenario een nieuw scherm moet aanmaken kun je gebruik gaan maken van (Web)block.
Hoe ziet dit eruit?
Je hebt één block waar de daadwerkelijk test wordt gedaan. Deze heeft een input record met daar in de gegevens die nodig zijn voor de test scenario.
Omdat de BDD test deze input structuur heeft kun je een nieuw block aanmaken die weer een lijst ombouwt met verschillende scenario’s.
Dit kan ook eenvoudig gedaan worden voor meerder tenants als dat nodig is. Maak eenvoudig verschillende pagina’s die aan het begin van het inladen een tenant switch toepassen.
Automatiseer je BDD testen.
Nu je klaar bent met je BDD testen heb je verschillende schermen met verschillende testen. Niet handig dat je nu alle schermen één voor één moet openen. Dit kan eenvoudiger en dat dachten wij ook. De BDD testen hebben een eigen API waar mee ze het testresultaat van een BDD test scherm kunnen ophalen.
Daar hebben we alleen de module- en paginanaam voor nodig om dat resultaat mee op te halen. Maar hoe maak je dit eenvoudig zodat je alle resultaten op het scherm kan weergeven?
We hebben dit gerealiseerd door middel van de modules waar we de BDD testen hebben staan een standaard naam te geven. Onze modules beginnen met onze applicatie naam vervolgens met een “_” en op het einde weer “_” met als volg Test.
Ditzelfde hebben we gedaan met de paginanamen. Die beginnen altijd met UnitTest_. Op deze manier voorkom je dat hij pagina’s wil gaan aanroepen die geen BDD testen bevatten.
Waarom hebben we dit precies gedaan?
Outsystems heeft systeem tabellen waar je mee modules maar ook pagina’s mee op kan zoeken. Door deze namen in de specifieke modules en pagina’s kunnen we de BDD API correct aanroepen.
Vervolgens hebben we een eigen tabel gemaakt die al deze losse resultaten opslaat en weer op een pagina weergeeft.
Dit proces wordt door een timer dagelijks aangeroepen waardoor wij elke ochtend kunnen zien welke testen er zijn gefaald. Deze resultaten kunnen nu ook gelijk gebruikt worden als je dit bijvoorbeeld wilt gaan gebruiken in een pipeline. Dan weet je direct dat je code nog steeds correct werkt op de volgende omgeving.
We hopen hiermee niet alleen de developers maar ook andere mensen van het team een beter beeld geschetst te hebben wat het BDDFramework voor jou kan beteken.
Niet alleen hoe je nu test-driven kan developen maar ook hoe belangrijk het BDDFramework kan zijn om de kwaliteit van je code in de toekomst te kunnen waarborgen.
Erwin Edel
OutSystems Consultants bij Conspect
