Hallo allemaal, hier is het ! Veel mensen kennen ons misschien al van . Voor degenen die net zijn aangesloten: wij ontwikkelen een IDE voor het werken met de API TestMace. De meestgestelde vraag bij het vergelijken van TestMace met concurrerende producten is: "Hoe onderscheiden jullie je van Postman?". We vonden dat het tijd was om een uitgebreid antwoord op deze vraag te geven. Hieronder hebben we onze voordelen ten opzichte van .
Opsplitsing in knooppunten
Als je met Postman werkt, weet je dat de interface voor aanvragen alle noodzakelijke functionaliteit bevat. Hier zijn scripts, tests en de aanvragen zelf. Dit vergemakkelijkt het werk voor nieuwkomers, maar bij grotere scenario's is deze benadering niet flexibel. Wat als je meerdere aanvragen wilt maken en gegevens wilt aggregeren? Wat als je een script zonder aanvraag wilt uitvoeren of meerdere logisch gescheiden scripts achter elkaar? Uiteindelijk zou het mooi zijn om tests van gewone utilitaire scripts te scheiden. Bovendien is de aanpak van "voeg alle functionaliteit in Ć©Ć©n knooppunt toe" niet schaalbaar ā de interface raakt snel overbelast.
TestMace splitst vanaf het begin alle functionaliteit op in verschillende soorten knooppunten. Wil je een aanvraag doen? Hier is je knooppunt. Wil je een script schrijven? Hier is je knooppunt. Heb je tests nodig? Alsjeblieft ā knooppunt. Oh ja, je kunt al deze zaken ook nog eens verpakken in een 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?
Menselijke leesbaar projectformaat
Tussen TestMace en Postman is er een conceptueel verschil in de manier van opslaan. In Postman worden alle aanvragen ergens in de lokale opslag bewaard. Als het nodig is om aanvragen tussen meerdere gebruikers te delen, moet je gebruik maken van de ingebouwde synchronisatie. Dit is eigenlijk een gangbare aanpak, maar niet zonder nadelen. Hoe zit het met de beveiliging van gegevens? De beleidslijnen van sommige bedrijven kunnen het misschien niet toestaan dat gegevens bij derde partijen worden opgeslagen. Wij geloven echter dat TestMace iets beters kan bieden! En deze verbetering heet "menselijke leesbaar projectformaat".
Laten we beginnen met het feit dat TestMace in principe de entiteit āprojectā heeft. De applicatie is oorspronkelijk ontwikkeld met het oog op het opslaan van projecten in versiesystemen: de projectstructuur projecteert praktisch Ć©Ć©n op Ć©Ć©n 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 ā alle veldnamen hebben logische benamingen.
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 ā wat je maar wilt), start de CI (je favoriete, niet opgelegde) onze consoletool. , 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.
Zoals je ziet, legt TestMace zijn ecosysteem en paradigma niet op. In plaats daarvan integreert het soepel in reeds gevestigde processen.
Dynamische variabelen
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.
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:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);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:
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:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Nou, hiervoor heeft TestMace 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:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));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)} toewijzen aan de variabele, die wordt aangemaakt via de grafische interface!
Testen maken via de GUI
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 ā bijna ongelimiteerde flexibiliteit, beschikbare oplossingen, etc.
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:
Echter, het creƫren van tests in de grafische editor sluit de mogelijkheid niet uit . Hier zijn dezelfde bibliotheken als in de scriptnode, en voor het schrijven van tests.
De mogelijkheid om een bestaande scenario via een link uit te voeren (Link node)
komt vaak voor situaties waarin een bepaalde aanvraag of zelfs een heel scenario meerdere keren op verschillende delen van het project moet worden uitgevoerd. Voorbeelden van dergelijke verzoeken kunnen een aangepaste multi-stage autorisatie zijn, het brengen van de omgeving in de gewenste toestand, enz. Kortom, als we in termen van programmeertalen spreken, zouden we functies willen hebben die hergebruikt kunnen worden in verschillende delen van de applicatie. In TestMace vervult deze functie Het is heel eenvoudig om het te gebruiken:
1) maak een verzoek of script aan
2) maak een knooppunt van het type Link
3) geef in de parameters de link op naar het script dat in de eerste stap is aangemaakt
In een geavanceerdere variant kun je aangeven welke dynamische variabelen uit het script naar het bovenliggende niveau moeten worden doorgestuurd ten opzichte van de link. Klinkt verwarrend? Stel dat we een Map met de naam create-post, waarin aan dit knooppunt een dynamische variabele wordt toegewezen postId. Nu kun je in het Link-knooppunt create-post-link expliciet opgeven dat de variabele postId toegekend moet worden aan het bovenliggende. create-post-linkDit mechanisme (opnieuw in programmeertaal) kan worden gebruikt om een resultaat uit een "functie" terug te geven. Kortom, het is geweldig, DRY in volle gang en opnieuw is er geen enkele regel code aangetast.
Wat betreft Postman, het feature request voor het hergebruiken van verzoeken , en er zijn zelfs , dat er aan dit probleem wordt gewerkt. In zijn huidige vorm heeft Postman natuurlijk de mogelijkheid om de uitvoeringsstroom te wijzigen, wat in theorie misschien dit gedrag mogelijk maakt, maar dit is eerder een vieze hack dan echt een werkbare aanpak.
Andere verschillen
- Groter controle over de reikwijdte van variabelen. De kleinste scope waarin een variabele in Postman kan worden gedefinieerd, is een collectie. TestMace staat toe variabelen voor elke aanvraag of map te definiƫren. In Postman stelt de optie Share collection alleen in staat om collecties te exporteren, terwijl in TestMace de sharing voor elk knooppunt werkt.
- TestMace ondersteunt , die standaard kunnen worden toegevoegd aan kindaanvragen. Postman heeft hier , en het is zelfs gesloten, maar als oplossing wordt voorgesteldā¦ . In TestMace wordt dit alles geconfigureerd via de GUI en is er een optionele mogelijkheid om geĆ«rfde headers in specifieke nakomelingen uit te schakelen.
- Undo/Redo. Werkt niet alleen bij het bewerken van knooppunten, maar ook bij verplaatsen, verwijderen, hernoemen en andere acties die de projectstructuur wijzigen.
- Bestanden die aan verzoeken zijn gehecht, worden een onderdeel van het project en worden samen met het project opgeslagen, waarbij ze perfect synchroniseren, in tegenstelling tot Postman. (Ja, het is niet langer nodig om bij elke uitvoer handmatig bestanden te selecteren en deze in archieven aan collegaās door te geven.)
Functies die al op komst zijn
We couldn't resist the temptation to lift the veil of mystery over the upcoming releases, especially since the functionality is very appealing and is already in pre-release polishing. So, let's welcome.
Functies
As you know, dynamic variables are used in Postman to generate values. and the vast majority of functions serve to generate fake values. For example, to generate a random email, you need to write:
{{ $randomEmail }}However, since they are variables (even if dynamic), they cannot be used as functions: they are not parameterizable, therefore you cannot take a hash of the string.
In TestMace, we plan to add 'honest' functions. Right within ${}, you will be able not only to refer to a variable but also to call a function. That is, if you need to generate the notorious fake email, we will simply write
${faker.internet.email()}Besides being a function, you can see that there is an option to call a method of an object. Instead of a large flat list of dynamic variables, we have a set of logically grouped objects.
But what if we want to compute a hash of a string? Easy!
${crypto.MD5($dynamicVar.data)}It can be noted that you can even pass variables as parameters! At this point, an inquisitive reader might suspect something is amissā¦
Using JavaScript in expressions
ā¦ And rightly so! When the requirements for the functions were formed, we suddenly came to the conclusion that valid JavaScript should be written in expressions. Therefore, you are now free to write expressions such as:
${1 + '' + crypto.MD5('asdf')}And all this without scripts directly in the input fields!
As for Postman, here you can only use variables, and when trying to write even the simplest expression, the validator complains and refuses to calculate it.
Advanced autocomplete
Currently, TestMace has standard autocomplete, which looks as follows:
Here, in addition to the autocompleting string, it indicates what this string belongs to. This mechanism only works in expressions enclosed in ${}.
Zoals je kunt zien, zijn er visuele markers toegevoegd die het type variabele aangeven (bijvoorbeeld string, nummer, array, enz.). Ook kunnen de autocompletion-modi worden gewijzigd (bijvoorbeeld je kunt autocompletion met variabelen of headers kiezen). Maar dat is niet het belangrijkste!
Ten eerste werkt autocompletion zelfs in expressies (waar dat mogelijk is). Zo ziet het eruit:
En ten tweede is autocompletion nu ook beschikbaar in scripts. Kijk eens hoe dat werkt!
Het heeft geen zin om deze functionaliteit met Postman te vergelijken ā daar is autocompletion beperkt tot statische lijsten van variabelen, headers en hun waarden (corrigeer me als ik iets vergeten ben). Scripts worden niet automatisch aangevuld š
Conclusie
In oktober was het een jaar geleden dat we met de ontwikkeling van ons product begonnen. In de tussentijd hebben we veel gedaan en op sommige punten zijn we onze concurrenten ingehaald. Maar hoe dan ook, ons doel is om een echt gebruiksvriendelijke tool voor API-werk te maken. We hebben nog een lange weg te gaan; hier is een globale ontwikkelingsplanning voor ons project voor het komende jaar: .
Jouw feedback helpt ons om beter te navigeren in de overvloed aan functies, en jouw steun geeft ons kracht en vertrouwen dat we het juiste doen. Het blijkt dat vandaag een belangrijke dag is voor ons project ā de publicatiedag van TestMace op . Steun ons project alsjeblieft; dat is heel belangrijk voor ons. Bovendien hebben we vandaag een aantrekkelijk aanbod op onze PH-pagina, en het is beperkt
Bron: habr.com
