{"id":54188,"date":"2019-12-20T00:00:00","date_gmt":"2019-12-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chem-testmace-luchshe-postman"},"modified":"2020-02-18T14:02:10","modified_gmt":"2020-02-18T11:02:10","slug":"chem-testmace-luchshe-postman","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/chem-testmace-luchshe-postman","title":{"rendered":"Wat maakt TestMace beter dan Postman?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wat<\/p>\n

<\/p>\n

Hallo allemaal, hier is het TestMace<\/a><\/noindex>! Veel mensen kennen ons misschien al van onze<\/a><\/noindex> vorige<\/a><\/noindex> artikelen<\/a><\/noindex>. Voor degenen die net zijn aangesloten: we ontwikkelen een IDE voor het werken met de API TestMace. De meest gestelde vraag bij het vergelijken van TestMace met concurrerende producten is \u2014 \u00abWat maakt jullie anders dan Postman?\u00bb. We hebben besloten dat het tijd is om een uitgebreid antwoord op deze vraag te geven. Hieronder hebben we onze voordelen ten opzichte van Postman<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Opsplitsing in knooppunten<\/h2>\n

<\/p>\n

Als je met Postman werkt, weet je dat de interface voor verzoeken alle benodigde functionaliteit bevat. Hier zitten scripts, testen, en natuurlijk de verzoeken zelf. Dit vereenvoudigt het werk voor nieuwelingen, maar bij grotere scenario's is deze aanpak niet flexibel. Wat als je meerdere verzoeken wilt aanmaken en deze wilt aggregeren? Wat als je een script zonder verzoek wilt uitvoeren of verschillende logisch gescheiden scripts achter elkaar? Tenslotte zou het goed zijn om testen van gewone utilitaire scripts te scheiden. Daarnaast is de aanpak van \u00abvoeg alle functionaliteit in \u00e9\u00e9n node toe\u00bb niet schaalbaar \u2014 de interface raakt snel overvol.<\/p>\n

<\/p>\n

TestMace splitst vanaf het begin alle functionaliteit op in verschillende soorten knooppunten. Wil je een aanvraag doen? Hier is je request step<\/a><\/noindex> knooppunt. Wil je een script schrijven? Hier is je script<\/a><\/noindex> knooppunt. Heb je tests nodig? Alsjeblieft \u2014 Assertion<\/a><\/noindex> knooppunt. Oh ja, je kunt al deze zaken ook nog eens verpakken in een map<\/a><\/noindex> knooppunt. En dit alles laat zich gemakkelijk met elkaar combineren. Deze aanpak is niet alleen zeer flexibel, maar stelt, in overeenstemming met het principe van unieke verantwoordelijkheid, je in staat om alleen te gebruiken wat je op dat moment echt nodig hebt. Waarom zou ik scripts en tests nodig hebben als ik gewoon een aanvraag wil doen?<\/p>\n

<\/p>\n

Menselijke leesbaar projectformaat<\/h2>\n

<\/p>\n

Er is een conceptueel verschil tussen TestMace en Postman in de manier van opslag. In Postman worden alle verzoeken ergens in de lokale opslag bewaard. Als je verzoeken wilt delen tussen meerdere gebruikers, moet je gebruik maken van de ingebouwde synchronisatie. Dit is eigenlijk een algemeen geaccepteerde aanpak, maar niet zonder nadelen. Hoe zit het met de databeveiliging? Want het beleid van sommige bedrijven staat mogelijk niet toe om gegevens bij derden op te slaan. Maar wij denken dat TestMace iets beters kan bieden! En de naam van deze verbetering is \u00abmens-leesbaar projectformaat\u00bb.<\/p>\n

<\/p>\n

Laten we beginnen met het feit dat TestMace in principe de entiteit \u201cproject\u201d heeft. De applicatie is oorspronkelijk ontwikkeld met het oog op het opslaan van projecten in versiesystemen: de projectstructuur projecteert praktisch \u00e9\u00e9n op \u00e9\u00e9n naar de mappenstructuur, gebruikmakend van yaml als opslagn formaat (zonder onnodige haakjes en komma's), en de bestandsrepresentatie van elke knoop is gedetailleerd beschreven in de documentatie met opmerkingen. Maar in de meeste gevallen zul je daar niet naar kijken \u2014 alle veldnamen hebben logische benamingen. <\/p>\n

<\/p>\n

Wat biedt dit de gebruiker? Het stelt de gebruiker in staat om de workflow van het team op een zeer flexibele manier te wijzigen, gebruikmakend van vertrouwde benaderingen. Bijvoorbeeld, ontwikkelaars kunnen het project opslaan in dezelfde repository als de backend. In de takken kan de ontwikkelaar, naast het direct wijzigen van de codebase, bestaande testscripts en verzoekscenario's corrigeren. Nadat wijzigingen in de repository zijn vastgelegd (git, svn, mercurial \u2014 wat je maar wilt), start de CI (je favoriete, niet opgelegde) onze consoletool. testmace-cli<\/a><\/noindex>, en het rapport dat na uitvoering wordt verkregen (bijvoorbeeld in junit-formaat, dat ook wordt ondersteund in testmace-cli) wordt verzonden naar het desbetreffende systeem. En de eerder genoemde veiligheidskwestie is ook geen probleem meer.<\/p>\n

<\/p>\n

Zoals je ziet, legt TestMace zijn ecosysteem en paradigma niet op. In plaats daarvan integreert het soepel in reeds gevestigde processen.<\/p>\n

<\/p>\n

Dynamische variabelen<\/h2>\n

<\/p>\n

TestMace volgt het no-code principe: als het probleem zonder code opgelost kan worden, streven we ernaar die mogelijkheid te bieden. Werken met variabelen is precies die functionaliteit waarbij in de meeste gevallen programmering niet noodzakelijk is.<\/p>\n

<\/p>\n

Voorbeeld: we hebben een antwoord van de server ontvangen, en we willen een gedeelte van de response in een variabele opslaan. In Postman zouden we in het testscript (wat op zich al vreemd is) iets als volgt schrijven:<\/p>\n

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
Maar naar onze mening lijkt het schrijven van een script voor zo'n eenvoudige en vaak gebruikte scenario overbodig. Daarom biedt TestMace de mogelijkheid om een stukje van het antwoord aan een variabele toe te wijzen via de grafische interface. Kijk hoe eenvoudig dit is:<\/p>\n
<\/p>\n
\"Wat<\/p>\n
<\/p>\n
En nu zal deze dynamische variabele bij elke aanvraag worden bijgewerkt. Maar je zou kunnen tegenwerpen met het argument dat de Postman-aanpak flexibeler is en niet alleen toewijzing mogelijk maakt, maar ook enige preprocessing kan uitvoeren. Zo kun je het vorige voorbeeld aanpassen:<\/p>\n
<\/p>\n
var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", CryptoJS.MD5(jsonData.data));<\/code><\/pre>\n
<\/p>\n
Nou, hiervoor heeft TestMace script<\/a><\/noindex> een node die dit scenario dekt. Om het vorige geval te reproduceren, maar nu in TestMace, moet je na de aanvraag een scriptnode maken en de volgende code als script gebruiken:<\/p>\n
<\/p>\n
const data = tm.currentNode.prev.response.body.data;\ntm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));<\/code><\/pre>\n
<\/p>\n
Zoals je kunt zien, heeft de samenstelling van nodes hier ook goed gewerkt. Voor zo'n eenvoudig geval als hierboven beschreven, kun je het expressie ${crypto.MD5($response.data)}<\/code> toewijzen aan de variabele, die wordt aangemaakt via de grafische interface!<\/p>\n
<\/p>\n
Testen maken via de GUI<\/h2>\n
<\/p>\n
Postman maakt het mogelijk om tests te maken door scripts te schrijven (in het geval van Postman is dit JavaScript). Deze aanpak heeft alleen maar voordelen \u2014 bijna ongelimiteerde flexibiliteit, beschikbare oplossingen, etc.<\/p>\n
<\/p>\n
Echter, de realiteit is vaak zo (niet wij, maar het leven), dat de tester geen programmeervaardigheden heeft, terwijl hij of zij al nu waarde aan het team zou willen toevoegen. Voor dergelijke gevallen stelt TestMace je in staat om eenvoudige tests te maken via de grafische interface, zonder scripts te schrijven. Hier is bijvoorbeeld hoe het proces van het maken van een test eruitziet die waarden vergelijkt op gelijkheid:<\/p>\n
<\/p>\n
\"Wat<\/p>\n
<\/p>\n
Echter, het cre\u00ebren van tests in de grafische editor sluit de mogelijkheid niet uit om tests in code te schrijven<\/a><\/noindex>. Hier zijn dezelfde bibliotheken als in de scriptnode, en chai<\/a><\/noindex> voor het schrijven van tests.<\/p>\n
<\/p>\n
Andere verschillen<\/h2>\n
<\/p>\n