Als developer wil ik de Postman testcollecties zelf kunnen runnen en toch een badge krijgen

[joeribekker]

...zodat ik dit niet via het testplatform hoef uit te voeren.

Toelichting:

Het concrete probleem is dat bijv. Travis wel een Docker container kan starten met daarin een API maar niet een publieke URL exposed voor deze Docker container. Deze publieke URL is wel nodig voor het API testplatform.

Oplossingsrichting:

Als alternatief willen we nu de test scenario's "downloaden" naar onze CI-omgeving, lokaal uitvoeren met newman, en de resultaten bijv. opsturen naar het API testplatform om alsnog een badge te verkrijgen.

Deze badge zou dan wel iets moeten hebben van "self-signed" ofzo, aangezien je makkelijk kan frauderen op deze manier. Wel lost dit het probleem op van een afgeschermde CI omgeving waar het API testplatform niet bij kan, en om alsnog een "echte" badge te verkrijgen moet je dan eenmalig per versie alles via het API testplatform runnen (maar dat kan handmatig).

Definition of ready

• [ ] Iedereen in het team begrijpt de user story
• [ ] Is klein genoeg (maximaal 1/3 van sprint)
• [ ] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door Henri)
• [ ] Voorzien van Acceptatiecriteria (duidelijk en testbaar)
• [ ] Voorzien van Definition of Done (duidelijk en testbaar)
• [ ] Voorzien van taken
• [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] API code
• [ ] API documentatie

Acceptatiecriteria

• [ ] Als developer kan ik een self-signed badge verkrijgen.

Taken

• [ ] API voor downloaden test scenario's (i.p.v. wget op Github URL ;p)
• [ ] API voor uploaden resultaten
• [ ] API geeft een (link naar) "self-signed" badge terug.

[alextreme]

(Joeri) Eerste prio: automatisch downloaden postman collection via API, normale/bruikbare URL

(Joeri) Resultaten uploaden: alleen interessant als er een badge te krijgen is, met als keerzijde dat dit fraudegevoelig is.

(optie) Gebruik van ngrok met travis, om zo de geteste webserver toegankelijk te maken voor het api testplatform.

@stevenbal wil hier naar kijken (volgens Joeri) https://assertible.com/blog/how-to-run-api-integration-tests-on-ci

[alextreme]

ATP API is uitgebreid met een call om de postman collection te downloaden, de API documentatie hiervoor wordt nog aangevuld ( /api/v1/postman-test/get_version/zds 2 verification with inner test/1.0.0/ ).

Daarna wordt deze user story op de backlog geplaatst: ngrok zou werken voor kleine postman collections maar gaat niet werken voor een grote Postman collection vanwege de 'connections per minute' ratelimiting (we doen nu momenteel circa 400 requests binnen 1 minuut, de gratis ngrok versie heeft 40 req/minuut en de duurste optie bij ngrok is 120 requests per minuut).

Een oplossing hiervoor is mogelijk door het uitvoeren van de tests via newman te vertragen. Dit is door @stevenbal uitgezocht en is een werkbare optie. Dit kan in een volgende sprint verder worden uitgezocht.

[alextreme]

Newman CLI optie die Steven noodzakelijk acht voor ngrok-gebruik:

--delay-request Specify the extent of delay between requests (milliseconds).

[alextreme]

Ngrok/vertragen optie is als #274 op de backlog gezet.

Aan @HenriKorver om te bepalen wat hiervoor nog nodig/wenselijk is.

[alextreme]

Ter info, er zijn alternatieven te bekijken naast ngrok die wellicht niet voor een beperking zorgen:

https://www.startpage.com/do/dsearch?query=ngrok+alternatives&cat=web&pl=ext-ff&language=english&extVersion=1.3.0

Vanuit het chatbot project ben ik in de weer met gitlab pipelines en continuous deployment en daarna automatisch testen, dit is een mogelijkheid maar wellicht teveel gevraagd voor normale lieden om dit via hun CI straat te laten inrichten...