Hoe ik testte
Ik deed requests via Postman en controleerde zowel de status als de inhoud. De screenshots laten de gebruikte queryparameters, response en aantallen geslaagde controles zien. De run-overzichten tonen één iteratie in DEV1.
Bij een fout kijk ik eerst of het testscript en de verwachte data kloppen. Daarna kijk ik in de mapping, code of Azure. Een response met status 200 is niet genoeg: bij organisations/{id} kwamen in één run alsnog zes inhoudelijke controles niet door.
Wat van mijn testscript zichtbaar is
In de course-screenshot en de programme-screenshot staat het begin van het Postman-script. Daarin staan pm.response.json(), een UUID-regex, een datumregex en allowedPageSizes = [10, 20, 50, 100, 250]. Ook zijn helpers voor queryparameters en expand zichtbaar. De screenshot laat een deel van het script zien, niet alle controles.
Voorbeeld van een controle
Dit script heb ik als voorbeeld voor mijn portfolio geschreven. Het is niet het oorspronkelijke testscript. Dit voorbeeld past bij een course-detailrequest. De variabele courseId moet eerst uit een bestaande lijstresponse komen.
pm.test("Status is 200", () => pm.response.to.have.status(200));
pm.test("JSON bevat de gevraagde course", () => {
const course = pm.response.json();
pm.expect(course.courseId).to.eql(pm.environment.get("courseId"));
pm.expect(course.primaryCode).to.have.property("code");
pm.expect(course.name).to.be.an("array").that.is.not.empty;
});Voor lijstresponses controleer ik items als array en items.length <= pageSize. Ik verwacht niet altijd precies pageSize items, omdat de laatste pagina korter kan zijn. Voor programmes en organisations gebruik ik hun eigen id-velden.
Uitvoering vastleggen
De testresultaten zijn als screenshots beschikbaar. Een export van de Postman-collectie, de gekozen build en de negatieve runs ontbreekt. De resultaten hieronder komen uit de bestaande screenshots.