Hallo allemaal, alsjeblieft ! Wellicht kennen veel mensen ons van . Voor degenen die net lid zijn: we zijn een IDE aan het ontwikkelen om met de TestMace API te werken. De meest gestelde vraag bij het vergelijken van TestMace met concurrerende producten is: “Hoe verschilt u van Postman?” We besloten dat het tijd was om een gedetailleerd antwoord op deze vraag te geven. Hieronder hebben wij onze voordelen op een rij gezet .
Opsplitsen in knooppunten
Als u met Postman werkt, weet u dat de aanvraaginterface alle benodigde functionaliteit bevat. Er zijn scripts, tests en, in feite, de verzoeken zelf. Dit maakt het voor beginners gemakkelijker, maar in grote scenario's is deze aanpak niet flexibel. Wat als u meerdere query's wilt maken en er aggregatie op wilt uitvoeren? Wat als u een script wilt uitvoeren zonder een verzoek of meerdere logisch gescheiden scripts achter elkaar? Het is immers een goed idee om tests te scheiden van reguliere hulpprogrammascripts. Bovendien is de aanpak “alle functionaliteit in één knooppunt toevoegen” niet schaalbaar: de interface raakt snel overbelast.
TestMace verdeelt in eerste instantie alle functionaliteit in verschillende soorten knooppunten. Wilt u een verzoek indienen? Het is voor jou knooppunt Wil je een script schrijven? Het is voor jou knooppunt Testen nodig? Alsjeblieft - knooppunt Oh ja, je kunt dit hele ding nog inpakken knooppunt En dit alles is eenvoudig met elkaar te combineren. Deze aanpak is niet alleen zeer flexibel, maar stelt u, in overeenstemming met het principe van één verantwoordelijkheid, ook in staat alleen te gebruiken wat u op dat moment echt nodig heeft. Waarom heb ik scripts en tests nodig als ik alleen maar een verzoek wil doen?
Voor mensen leesbaar projectformaat
Er is een conceptueel verschil tussen TestMace en Postman in de manier waarop ze worden opgeslagen. In Postman worden alle verzoeken ergens in de lokale opslag opgeslagen. Als het nodig is om verzoeken tussen meerdere gebruikers te delen, moet u de ingebouwde synchronisatie gebruiken. In feite is dit een algemeen aanvaarde aanpak, maar niet zonder nadelen. Hoe zit het met de gegevensbeveiliging? Het beleid van sommige bedrijven staat immers mogelijk niet toe dat gegevens bij derden worden opgeslagen. Wij denken echter dat TestMace iets beters te bieden heeft! En de naam van deze verbetering is ‘voor mensen leesbaar projectformaat’.
Laten we beginnen met het feit dat er in TestMace in principe een 'project'-entiteit is. En de applicatie is in eerste instantie ontwikkeld met het oog op het opslaan van projecten in versiebeheersystemen: de projectboom wordt vrijwel één-op-één geprojecteerd op de bestandsstructuur, yaml wordt gebruikt als opslagformaat (zonder extra haakjes en komma’s), en de De bestandsrepresentatie van elk knooppunt wordt gedetailleerd beschreven in de documentatie met commentaar. Maar in de meeste gevallen zul je daar niet zoeken: alle veldnamen hebben logische namen.
Wat levert dit de gebruiker op? Hierdoor kunt u de werkstroom van het team zeer flexibel veranderen, met behulp van vertrouwde benaderingen. Ontwikkelaars kunnen een project bijvoorbeeld in dezelfde repository opslaan als de backend. In branches kan de ontwikkelaar, naast het wijzigen van de codebasis zelf, bestaande queryscripts en tests corrigeren. Na het doorvoeren van wijzigingen in de repository (git, svn, mercurial - wat je maar het leukst vindt), lanceert CI (jouw favoriet, door niemand opgelegd) ons consolehulpprogramma , en het rapport dat na uitvoering wordt ontvangen (bijvoorbeeld in junit-indeling, dat ook wordt ondersteund in testmace-cli), wordt naar het juiste systeem verzonden. En het bovengenoemde beveiligingsprobleem is niet langer een probleem.
Zoals u kunt zien, legt TestMace zijn ecosysteem en paradigma niet op. In plaats daarvan past het gemakkelijk in gevestigde processen.
Dynamische variabelen
TestMace volgt het no-code-concept: als een probleem kan worden opgelost zonder code te gebruiken, proberen we deze mogelijkheid te bieden. Werken met variabelen is precies de functionaliteit waar je in de meeste gevallen zonder programmeren mee aan de slag kunt.
Voorbeeld: we hebben een antwoord ontvangen van de server en we willen een deel van het antwoord opslaan in een variabele. In Postman zouden we in een testscript (wat op zichzelf vreemd is) zoiets schrijven als:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);Maar naar onze mening lijkt het schrijven van een script voor zo’n eenvoudig en veelgebruikt scenario overbodig. Daarom is het in TestMace mogelijk om een deel van het antwoord aan een variabele toe te wijzen met behulp van de grafische interface. Kijk hoe eenvoudig het is:
En nu wordt deze dynamische variabele bij elk verzoek bijgewerkt. Maar u kunt bezwaar maken met het argument dat de Postman-aanpak flexibeler is en u niet alleen in staat stelt een opdracht te maken, maar ook enige voorbewerkingen uit te voeren. Zo wijzigt u het vorige voorbeeld:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Welnu, voor dit doel heeft TestMace knooppunt, dat dit scenario omvat. Om het vorige geval te reproduceren, maar al uitgevoerd door TestMace, moet u na het verzoek een scriptknooppunt maken en de volgende code als script gebruiken:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));Zoals je kunt zien, heeft de samenstelling van de knooppunten hier ook goed gewerkt. En voor zo'n eenvoudig geval als hierboven beschreven, kunt u eenvoudigweg de uitdrukking toewijzen ${crypto.MD5($response.data)} variabele gemaakt via de GUI!
Testen maken via GUI
Met Postman kunt u tests maken door scripts te schrijven (in het geval van Postman is dit JavaScript). Deze aanpak heeft veel voordelen: vrijwel onbeperkte flexibiliteit, beschikbaarheid van kant-en-klare oplossingen, enz.
De realiteit is echter vaak zodanig (zo zijn wij niet, zo is het leven) dat een tester geen programmeervaardigheden heeft, maar hij zou op dit moment graag voordeel voor het team willen opleveren. Voor dergelijke gevallen kunt u met TestMace, volgens het no-code-concept, eenvoudige tests maken via een GUI zonder toevlucht te hoeven nemen tot het schrijven van scripts. Hier ziet u bijvoorbeeld hoe het proces van het maken van een test die waarden voor gelijkheid vergelijkt, eruit ziet:
Het maken van tests in een grafische editor elimineert deze mogelijkheid echter niet . Hier bevinden zich dezelfde bibliotheken als in het scriptknooppunt, en voor het schrijven van toetsen.
Mogelijkheid om een bestaand script uit te voeren via een link (Link node)
Vaak ontstaan er situaties waarin een bepaalde query of zelfs een heel script meerdere keren moet worden uitgevoerd in verschillende delen van het project. Een voorbeeld van dergelijke verzoeken kan zijn aangepaste meertrapsautorisatie, waardoor de omgeving in de gewenste staat wordt gebracht, enz. Over het algemeen zouden we, in termen van programmeertalen, graag functies willen hebben die in verschillende delen van de applicatie kunnen worden hergebruikt. In TestMace wordt deze functie uitgevoerd door knooppunt Het is heel gemakkelijk te gebruiken:
1) maak een query of script
2) maak een knooppunt van het type Link
3) geef in de parameters een link op naar het script dat in de eerste stap is gemaakt
In een meer geavanceerde versie kun je opgeven welke dynamische variabelen uit het script ten opzichte van de link naar een hoger niveau worden doorgegeven. Klinkt verwarrend? Laten we zeggen dat we een map met de naam hebben gemaakt maak-post, waarbinnen een dynamische variabele aan dit knooppunt wordt toegewezen postId. Nu in Link-knooppunt maak-post-link u kunt expliciet opgeven dat de variabele postId toegewezen aan een voorouder maak-post-link. Dit mechanisme (opnieuw in programmeertaal) kan worden gebruikt om een resultaat van een “functie” terug te geven. Over het algemeen is het cool, DRY is in volle gang en opnieuw is geen enkele regel code beschadigd.
Wat Postman betreft, is er een functieverzoek voor het hergebruiken van verzoeken , en het lijkt erop dat dat zelfs zo is dat ze aan dit probleem werken. In zijn huidige vorm heeft Postman uiteraard het vermogen om de uitvoeringslijn te veranderen, wat het in theorie waarschijnlijk mogelijk maakt om soortgelijk gedrag te implementeren, maar dit is meer een vuile hack dan een echt werkende aanpak.
Andere verschillen
- Meer controle over de reikwijdte van variabelen. Het kleinste bereik waarbinnen een variabele in Postman kan worden gedefinieerd, is verzameling. Met TestMace kunt u variabelen definiëren voor elke query of map. In Postman Share kunt u met verzamelingen alleen verzamelingen exporteren, terwijl delen in TestMace voor elk knooppunt werkt
- TestMace ondersteunt , die standaard in onderliggende query's kan worden vervangen. Postman heeft hier iets over: , en het is zelfs gesloten, maar het wordt wel als oplossing aangeboden... . In TestMace wordt dit allemaal geconfigureerd via de GUI en is er een optie om optioneel overgenomen headers in specifieke nakomelingen uit te schakelen
- Ongedaan maken/opnieuw. Werkt niet alleen bij het bewerken van knooppunten, maar ook bij het verplaatsen, verwijderen, hernoemen en andere bewerkingen die de structuur van het project veranderen
- Bestanden die aan verzoeken zijn gekoppeld, worden onderdeel van het project en worden ermee opgeslagen, terwijl ze, in tegenstelling tot Postman, perfect gesynchroniseerd zijn. (Ja, u hoeft niet langer elke keer dat u opstart handmatig bestanden te selecteren en over te dragen aan collega's in archieven)
Functies die al onderweg zijn
We konden de verleiding niet weerstaan om de sluier van geheimhouding over de volgende releases op te lichten, vooral wanneer de functionaliteit erg lekker is en al vóór de release wordt gepolijst. Dus laten we elkaar ontmoeten.
functies
Zoals u weet gebruikt Postman zogenaamde dynamische variabelen om waarden te genereren. en de overgrote meerderheid van de functies wordt gebruikt om valse waarden te genereren. Om bijvoorbeeld een willekeurige e-mail te genereren, moet u het volgende schrijven:
{{$randomEmail}}Omdat dit echter variabelen zijn (zij het dynamisch), kunnen ze niet als functies worden gebruikt: ze zijn niet parametreerbaar, daarom is het niet mogelijk om een hash uit een string te halen.
We zijn van plan om “eerlijke” functies aan TestMace toe te voegen. Binnen ${} is het niet alleen mogelijk om toegang te krijgen tot een variabele, maar ook om een functie aan te roepen. Die. als je de beruchte nep-e-mail moet genereren, zullen we gewoon schrijven
${faker.internet.email()}Naast dat het een functie is, zul je merken dat het mogelijk is om een methode aan te roepen op een object. En in plaats van een grote platte lijst met dynamische variabelen hebben we een reeks logisch gegroepeerde objecten.
Wat als we de hash van een string willen berekenen? Gemakkelijk!
${crypto.MD5($dynamicVar.data)}U zult merken dat u zelfs variabelen als parameters kunt doorgeven! Op dit punt kan een nieuwsgierige lezer vermoeden dat er iets mis is...
JavaScript gebruiken in expressies
... En met goede reden! Toen de eisen voor functies werden gevormd, kwamen we plotseling tot de conclusie dat geldig javascript in expressies geschreven moest worden. U bent nu dus vrij om uitdrukkingen te schrijven als:
${1 + '' + crypto.MD5('asdf')}En dit allemaal zonder scripts, direct in de invoervelden!
Wat Postman betreft, hier kun je alleen variabelen gebruiken, en wanneer je de geringste uitdrukking probeert te schrijven, vloekt de validator en weigert deze te berekenen.
Geavanceerde automatische aanvulling
Momenteel heeft TestMace een standaard automatische aanvulling die er als volgt uitziet:
Hier wordt naast de autoaanvulregel aangegeven waar deze regel bij hoort. Dit mechanisme werkt alleen in expressies omgeven door haakjes ${}.
Zoals u kunt zien, zijn er visuele markeringen toegevoegd die het type variabele aangeven (bijvoorbeeld string, getal, array, enz.). U kunt ook de modi voor automatisch aanvullen wijzigen (u kunt bijvoorbeeld automatisch aanvullen met variabelen of kopteksten selecteren). Maar zelfs dit is niet het belangrijkste!
Ten eerste werkt automatisch aanvullen zelfs in expressies (waar mogelijk). Dit is hoe het eruit ziet:
En ten tweede is automatisch aanvullen nu beschikbaar in scripts. Kijk eens hoe het werkt!
Het heeft geen zin om deze functionaliteit te vergelijken met Postman - automatisch aanvullen is alleen beperkt tot statische lijsten met variabelen, headers en hun waarden (corrigeer me als ik iets ben vergeten). Scripts worden niet automatisch aangevuld :)
Conclusie
Oktober was een jaar geleden sinds de start van onze productontwikkeling. Gedurende deze tijd zijn we erin geslaagd veel dingen te doen en in sommige opzichten hebben we onze concurrenten ingehaald. Maar hoe het ook zij, ons doel is om een echt handig hulpmiddel te maken voor het werken met API's. We hebben nog veel werk te doen, hier is een globaal plan voor de ontwikkeling van ons project voor het komende jaar: .
Dankzij uw feedback kunnen we beter navigeren door de overvloed aan functies, en uw steun geeft ons de kracht en het vertrouwen dat we het juiste doen. Toevallig is vandaag een belangrijke dag voor ons project: de dag waarop TestMace werd gepubliceerd . Steun alstublieft ons project, het is erg belangrijk voor ons. Bovendien staat er vandaag een verleidelijke aanbieding op onze PH-pagina, en deze is beperkt
Bron: www.habr.com