Hej alla! Idag vill vi presentera vår produkt för IT-publiken - en IDE för att arbeta med API:er
Motivation
Jag skulle vilja börja med hur vi faktiskt kom till det här livet och bestämde oss för att skapa vårt eget verktyg för avancerat arbete med API. Låt oss börja med en lista över funktioner som en produkt bör ha, om vilken vi enligt vår åsikt kan säga att det är en "IDE för att arbeta med API:er":
- Skapa och köra frågor och skript (sekvenser av frågor)
- Skriver olika typer av prov
- Testgenerering
- Arbeta med API-beskrivningar, inklusive import från format som Swagger, OpenAPI, WADL, etc.
- Hånfulla förfrågningar
- Bra stöd för ett eller flera språk för att skriva manus, inklusive integration med populära bibliotek
- etc.
Listan kan utökas för att passa din smak. Dessutom är det viktigt att skapa inte bara själva IDE, utan också en viss infrastruktur, såsom molnsynkronisering, kommandoradsverktyg, onlineövervakningstjänst, etc. I slutändan dikterar de senaste årens trender för oss inte bara applikationens kraftfulla funktionalitet utan också dess trevliga gränssnitt.
Vem behöver ett sådant verktyg? Uppenbarligen är alla de som åtminstone på något sätt är kopplade till utveckling och testning av API:er utvecklare och testare =). Dessutom, om det för de förra ofta räcker att köra enstaka frågor och enkla skript, så är detta för testare ett av huvudverktygen, som bland annat bör inkludera en kraftfull mekanism för att skriva tester med möjlighet att köra dem i CI.
Så efter dessa riktlinjer började vi skapa vår produkt. Låt oss se vad vi har uppnått i det här skedet.
Snabb start
Låt oss börja med en första bekantskap med applikationen. Du kan ladda ner den
Klicka på plustecknet högst upp i innehållsområdet för att skapa din första förfrågan. Frågefliken ser ut så här:
Låt oss titta på det mer detaljerat. Förfrågningsgränssnittet är mycket likt gränssnittet för populära viloklienter, vilket gör migreringen från liknande verktyg enklare. Låt oss göra den första begäran till webbadressen
Generellt sett, vid första anblicken, ger inte heller svarspanelen några överraskningar. Jag skulle dock vilja fästa er uppmärksamhet på några punkter:
- Svarets kropp representeras i form av ett träd, som för det första lägger till informationsinnehåll och för det andra låter dig lägga till några intressanta funktioner om vilka nedan
- Det finns en Assertions-flik som visar en lista med tester för en given begäran
Som du kan se kan vårt verktyg användas som en bekväm viloklient. Vi skulle dock inte vara här om dess möjligheter endast var begränsade till att skicka förfrågningar. Därefter kommer jag att beskriva de grundläggande koncepten och funktionerna i TestMace.
Grundläggande koncept och funktioner
nod
TestMace funktionalitet är uppdelad i olika typer av noder. I exemplet ovan demonstrerade vi funktionen för RequestStep-noden. Men följande typer av noder är nu också tillgängliga i applikationen:
- RequestStep. Detta är noden genom vilken du kan skapa en förfrågan. Den kan bara ha en Assertion-nod som ett underordnat element.
- Påstående. Noden används för att skriva tester. Kan bara vara en underordnad nod till RequestStep-noden.
- Mapp. Låter dig gruppera mapp- och RequestStep-noder inom sig själva.
- Projekt. Detta är rotnoden som skapas automatiskt när projektet skapas. Annars upprepas funktionaliteten för mappnoden.
- Länk. Länk till mappen eller RequestStep-noden. Låter dig återanvända frågor och skript.
- etc.
Noderna är placerade i repor (panelen längst ner till vänster, används för att snabbt skapa "engångsfrågor") och i projekt (panelen längst upp till vänster), som vi kommer att uppehålla oss vid mer detaljerat.
Projekt
När du startar programmet kanske du märker en ensam projektrad i det övre vänstra hörnet. Detta är roten till projektträdet. När du startar ett projekt skapas ett tillfälligt projekt, vars väg beror på ditt operativsystem. Du kan när som helst flytta projektet till en plats som passar dig.
Huvudsyftet med projektet är möjligheten att spara utvecklingar i filsystemet och ytterligare synkronisera dem genom versionskontrollsystem, köra skript i CI, granska ändringar m.m.
variabler
Variabler är en av nyckelmekanismerna för en applikation. De av er som arbetar med verktyg som TestMace kanske redan har en uppfattning om vad vi pratar om. Så, variabler är ett sätt att lagra vanliga data och kommunicera mellan noder. En analog är till exempel miljövariabler i Postman eller Insomnia. Men vi gick vidare och utvecklade ämnet. I TestMace kan variabler ställas in på nodnivå. Några. Det finns också en mekanism för att ärva variabler från förfäder och överlappande variabler hos ättlingar. Dessutom finns det ett antal inbyggda variabler, namnen på de inbyggda variablerna börjar med $
. Här är några av dem:
$prevStep
— länk till variabler från föregående nod$nextStep
— länk till variabler för nästa nod$parent
- samma sak, men bara för förfadern$response
- svar från servern$env
- aktuella miljövariabler$dynamicVar
- dynamiska variabler skapade under körning av skript eller fråge
$env
- dessa är i huvudsak vanliga variabler på projektnodnivå, men uppsättningen miljövariabler ändras beroende på den valda miljön.
Variabeln nås via ${variable_name}
Värdet på en variabel kan vara en annan variabel, eller till och med ett helt uttryck. Till exempel kan url-variabeln vara ett uttryck som
http://${host}:${port}/${endpoint}
.
Separat är det värt att notera möjligheten att tilldela variabler under skriptkörning. Till exempel finns det ofta behov av att spara auktoriseringsdata (en token eller hela rubriken) som kom från servern efter en lyckad inloggning. TestMace låter dig spara sådana data i dynamiska variabler för en av förfäderna. För att undvika kollisioner med redan existerande "statiska" variabler placeras dynamiska variabler i ett separat objekt $dynamicVar
.
scenarier
Genom att använda alla ovanstående funktioner kan du köra hela frågeskript. Till exempel skapa en entitet -> fråga efter en entitet -> ta bort en entitet. I det här fallet kan du till exempel använda mappnoden för att gruppera flera RequestStep-noder.
Autokomplettering och uttrycksmarkering
För bekvämt arbete med variabler (och inte bara) är autokomplettering nödvändigt. Och naturligtvis att lyfta fram värdet av ett uttryck för att göra det enklare och bekvämare att klargöra vad en viss variabel är lika med. Detta är precis fallet när det är bättre att se en gång än att höra hundra gånger:
Det är värt att notera att autokomplettering implementeras inte bara för variabler utan även för till exempel rubriker, värden för vissa rubriker (till exempel autokomplettering för Content-Type-huvudet), protokoll och mycket mer. Listan uppdateras ständigt i takt med att applikationen växer.
Ångra göra om
Att ångra/göra om ändringar är en mycket bekväm sak, men av någon anledning är det inte implementerat överallt (och verktyg för att arbeta med API:er är inget undantag). Men vi är inte en av dem!) Vi har implementerat ångra/gör om genom hela projektet, vilket gör att du kan ångra inte bara redigering av en specifik nod, utan även dess skapande, radering, rörelse osv. De mest kritiska operationerna kräver bekräftelse.
Skapar tester
Assertion-noden är ansvarig för att skapa tester. En av huvudfunktionerna är möjligheten att skapa tester utan programmering, med hjälp av inbyggda editorer.
En påståendenod består av en uppsättning påståenden. Varje påstående har sin egen typ, för närvarande finns det flera typer av påståenden
-
Jämför värden - jämför helt enkelt 2 värden. Det finns flera jämförelseoperatorer: lika, inte lika, större än, större än eller lika med, mindre än, mindre än eller lika med.
-
Innehåller värde - kontrollerar förekomsten av en delsträng i en sträng.
-
XPath - kontrollerar att väljaren i XML innehåller ett visst värde.
-
JavaScript-påstående är ett godtyckligt javascript-skript som returnerar sant vid framgång och falskt vid misslyckande.
Jag noterar att endast den sista kräver programmeringskunskaper från användaren, de andra 3 påståendena skapas med hjälp av ett grafiskt gränssnitt. Här är till exempel hur dialogrutan för att skapa ett jämför värdepåstående ser ut:
Grädden på moset är det snabba skapandet av påståenden från svar, titta bara på det!
Sådana påståenden har dock uppenbara begränsningar, som du kanske vill använda ett javascript-påstående för att övervinna. Och här ger TestMace också en bekväm miljö med autokomplettering, syntaxmarkering och till och med en statisk analysator.
API-beskrivning
TestMace låter dig inte bara använda API:t, utan också att dokumentera det. Dessutom har själva beskrivningen en hierarkisk struktur och passar organiskt in i resten av projektet. Dessutom är det för närvarande möjligt att importera API-beskrivningar från Swagger 2.0 / OpenAPI 3.0-format. Beskrivningen i sig ligger inte bara i dödvikt, utan är nära integrerad med resten av projektet, i synnerhet är autokomplettering av webbadresser, HTTP-rubriker, frågeparametrar, etc. tillgängligt, och i framtiden planerar vi att lägga till tester för överensstämmelse av svaret med API-beskrivningen.
Delningsnod
Fall: du vill dela en problematisk begäran eller till och med ett helt skript med en kollega eller helt enkelt bifoga det till en bugg. TestMace täcker också detta fall: applikationen låter dig serialisera vilken nod som helst och till och med ett underträd i en URL. Copy-paste och du kan enkelt överföra förfrågan till en annan maskin eller projekt.
Människoläsbart projektlagringsformat
För tillfället lagras varje nod i en separat fil med yml-tillägget (som är fallet med Assertion-noden), eller i en mapp med namnet på noden och filen index.yml.
Så här ser till exempel förfrågningsfilen som vi gjorde i granskningen ovan ut:
index.yml
children: []
variables: {}
type: RequestStep
assignVariables: []
requestData:
request:
method: GET
url: 'https://next.json-generator.com/api/json/get/NJv-NT-U8'
headers: []
disabledInheritedHeaders: []
params: []
body:
type: Json
jsonBody: ''
xmlBody: ''
textBody: ''
formData: []
file: ''
formURLEncoded: []
strictSSL: Inherit
authData:
type: inherit
name: Scratch 1
Som du kan se är allt väldigt tydligt. Om så önskas kan detta format enkelt redigeras manuellt.
Hierarkin av mappar i filsystemet upprepar helt hierarkin av noder i projektet. Till exempel ett skript som:
Mappar filsystemet till följande struktur (endast mapphierarkin visas, men kärnan är tydlig)
Detta gör projektgranskningen lättare.
Import från Postman
Efter att ha läst allt ovan, kommer vissa användare att vilja prova (rätt?) en ny produkt eller (vad fan skojar inte!) helt använda den i sitt projekt. Migrationen kan dock stoppas av ett stort antal utvecklingar i samma Postman. I sådana fall stöder TestMace import av samlingar från Postman. För närvarande stöds importer utan tester, men vi utesluter inte att stödja dem i framtiden.
planer
Jag hoppas att många av dem som har läst hittills har gillat vår produkt. Det är dock inte allt! Arbetet med produkten är i full gång och här är några funktioner som vi planerar att lägga till snart.
Molnsynkronisering
En av de mest efterfrågade funktionerna. För tillfället föreslår vi att använda versionskontrollsystem för synkronisering, för vilket vi gör formatet mer användarvänligt för denna typ av lagring. Detta arbetsflöde är dock inte lämpligt för alla, så vi planerar att lägga till en synkroniseringsmekanism som är bekant för många via våra servrar.
CLI
Som nämnts ovan kan produkter på IDE-nivå inte klara sig utan alla typer av integrationer med befintliga applikationer eller arbetsflöden. CLI är precis vad som behövs för att integrera tester skrivna i TestMace i den kontinuerliga integrationsprocessen. Arbetet med CLI är i full gång; tidiga versioner kommer att lansera projektet med en enkel konsolrapport. I framtiden planerar vi att lägga till rapportutdata i JUnit-format.
Plugin-system
Trots all kraft i vårt verktyg är uppsättningen av fall som kräver lösningar obegränsad. Det finns trots allt uppgifter som är specifika för ett visst projekt. Det är därför vi i framtiden planerar att lägga till en SDK för att utveckla plugins och varje utvecklare kommer att kunna lägga till funktionalitet efter eget tycke.
Utöka utbudet av nodtyper
Denna uppsättning noder täcker inte alla fall som krävs av användaren. Noder som planeras läggas till:
- Skriptnod - konverterar och placerar data med hjälp av js och motsvarande API. Med den här typen av noder kan du göra saker som förhandsbegäran och skript efter begäran i Postman.
- GraphQL-nod - stöd för graphql
- Anpassad påståendenod - låter dig utöka uppsättningen av befintliga påståenden i projektet
Naturligtvis är detta inte en slutgiltig lista, den kommer att uppdateras ständigt på grund av bland annat din feedback.
FAQ
Hur skiljer du dig från Postman?
- Konceptet med noder, vilket gör att du nästan oändligt kan skala projektets funktionalitet
- Människoläsbart projektformat med att spara det i ett filsystem, vilket förenklar arbetet med versionskontrollsystem
- Möjlighet att skapa tester utan programmering och mer avancerad js-stöd i testredigeraren (autokomplettering, statisk analysator)
- Avancerad autokomplettering och markering av det aktuella värdet av variabler
Är detta en produkt med öppen källkod?
Nej, i nuläget är källorna stängda, men i framtiden överväger vi möjligheten att öppna källorna
Vad lever du av?)
Tillsammans med gratisversionen planerar vi att släppa en betalversion av produkten. Det kommer i första hand att innehålla saker som kräver en serversida, till exempel synkronisering.
Slutsats
Vårt projekt går med stormsteg mot en stabil release. Produkten kan dock redan användas, och den positiva feedbacken från våra tidiga användare är ett bevis på detta. Vi samlar aktivt in feedback, för utan nära samarbete med samhället är det omöjligt att bygga ett bra verktyg. Du hittar oss här:
Vi ser fram emot dina önskemål och förslag!
Källa: will.com