Hyperledger Fabric Tutorial: Omfattande guide – Del 3

Följande handledningsserie består av tre artiklar som kommer att lära dig olika aspekter om Hyperledger Fabric kedjekodsutveckling, allt från CRUD-operationer, dataskydd och kedjekodstestning.

Del 1

Del 2

Del 3

Hyperledger Fabric Tutorial: Comprehensive Guide - Part 2

En översikt över serien:

  • Artikel 1: Grundläggande utveckling av kedjekod och lagring av privat data i samlingar
  • Artikel 2: Avancerade kedjekodsfrågor och CouchDB GUI
  • Artikel 3: En handledning för att testa din kedjekod med MockStub

Krav

  • 4 GB RAM (mer föredras)
  • Docker, Docker-Compose, kodredigerare (t.ex. Visual Studio Code), Git
  • NodeJS version 8.9+ (Föredras är 8.9.4 – Tips: ändra din version med en versionshanterare som ”n‘)
  • Grundläggande JavaScript-kunskap

Mål

  • Lär dig att testa dina kedjekodsfunktioner
  • Lär dig att håna och åberopa funktioner
  • Jämför resultat med Chai-test

Introduktion

I de tidigare två artiklarna har vi lärt oss att skapa både grundläggande och mer avancerade kedjekodsfunktioner. Vikten av att testa din kedjekod kan inte underskattas. Ett enda misstag kan få dramatiska konsekvenser när man hanterar smarta kontrakt. Därför kommer vi att testa kvaliteten på våra kedjekodsfunktioner.

Komma igång

Se till att du har en kopia av koden som finns på Github michielmulders / hyperledger-fabric-blockgeeks. Det rekommenderas att använda git klon https://github.com/michielmulders/hyperledger-fabric-blockgeeks.git för att skapa en lokal klon av förvaret på din maskin. Använda sig av git checkout tutorial-3 för att öppna koden för den här självstudien och kolla in den tredje delen av handledningen med git checkout tutorial-3

Om du är ny med den här självstudien, se till att kolla in avsnittet “Boilerplate setup” i den första artikeln för att komma igång.

Nu ska vi navigera med din terminal till kedjekod / nod mapp. Härifrån kan vi springa npm körtest för att starta våra tester. Själva testerna finns på kedjekod / nod / test / tests.spec.ts. Låt oss ta en titt på dessa tester.

Testning med Mockstub

Jonas Snellinckx från TheLedger förklarar vad ChaincodeMockStub är, ”Denna ChaincodeMockStub är en mock implementering av tyg-shim stubben. Det betyder att du kan testa din kedjekod utan att starta ditt nätverk. Den implementerar nästan alla funktioner som själva stubben gör, men i minnet. Endast dessa funktioner stöds (ännu) inte: getHistoryForKey, getBinding, getTransient, setEvent, getChannelID. ”

Kedjekodstestning

För att komma igång måste vi importera “förvänta” -funktionen från Chai testpaket så att vi kan använda olika jämförelsemekanismer som att jämföra svarobjekt eller statuskoder. Chai är ett BDD / TDD-påståendebibliotek för nod och webbläsare som härligt kan paras ihop med alla javascript-testramar.

importera {expect} från “chai”;

Om du tittar på tests.spec.ts filen kan du se att vi grupperar tester tillsammans med beskriva funktion är detta bara en allmän kodstilspraxis. Därefter använder vi den funktion för att definiera enskilda tester.

De flesta tester börjar med att skapa en ny instans av vår kedjekod. Detta är inte alltid nödvändigt eftersom vi också kan definiera en global instans av vår kedjekod som vi kan anropa och åberopa funktioner på från varje test. Detta beror på hur och vad du vill testa, för det mesta försöker vi skriva enhetstester, bara testa kärnfunktionaliteten för en funktion. För det mesta definierar vi en ny kedjekodsinstans, men vi kommer också att starta en global kedjekodsinstans med instanserad bildata som kan användas i flera tester. Låt oss skriva våra första tester!

1. Slutförande av initial kedjekod

Testa InitLedger

Först och främst börjar vårt nätverk med att ringa initLedger funktion som fyller vår blockchain med bildata. För att se till att resten av vår kedjekod fungerar ordentligt, måste vi testa status för denna funktion och kontrollera om all data finns i blockchain-tillståndet.

Vi börjar med att importera kedjekoden och skapa en instans så att vi kan komma åt alla funktioner vi har definierat.

importera {MyChaincode} från ‘../src/MyChaincode’;

const chaincode = ny MyChaincode ();

Därefter kan vi definiera vårt första testfall, ge det en meningsfull beskrivning. Som du kan se definierar vi en ny mockstub-instans som vi bara kommer att använda i detta test eftersom vi vill vara säkra på att vår kedjekod kompileras korrekt. De mockInit funktionen initierar kedjekoden (anropar initLedger-funktionen). Vi ger det ett unikt transaktions-ID tx1 och skicka en tom matris eftersom det inte kräver några argument. När kedjekoden initialiseras vill vi testa körningsstatusen och se till att allt lyckades. Lika metoden för Chai förväntar funktionalitet kommer till nytta för att jämföra status.

den("Bör initiera utan problem", async () => {

       const stub = ny ChaincodeMockStub ("MyMockStub", kedjekod);

       const response = väntar på stub.mockInit ("tx1", []);

       förvänta dig (response.status) .to.eql (200)

});

Både mockInit och mockInvoke funktion returnera följande löfteobjekt:

Löfte<{

   status: nummer;

   meddelande: sträng;

   nyttolast: buffert;

}>

Verifiera initialiserade data

För närvarande är vi säkra på att kedjekoden har sammanställts och initialiserats korrekt. Vi är dock inte säkra på om all data är korrekt bifogad till vårt blockchain-tillstånd. Låt oss testa frågan om alla funktioner för att jämföra de returnerade bilobjekten med de förväntade bilarna.

Den här gången skapar vi en global instans av kedjekodens mockstub.

den("Bör kunna initiera och fråga alla bilar", async () => {

       stubWithInit = ny ChaincodeMockStub ("MyMockStub", kedjekod);

       …

}

Den här gången mockInvoke funktionen används för att anropa funktionen queryAllCars i kedjekoden. De queryResponse.payload innehåller en buffert som vi kan använda i vår jämförelsesfunktion. TheLedger har tillhandahållit en hjälpare som konverterar en buffertnyttolast till ett JSON-objekt med Omvandla hjälpare från @ theledger / tyg-mock-stub. Funktionen förvänta innehåller en djup metod som kan jämföra JSON-objekt helt. Vi jämför resultatet med de ursprungliga objekten som vi har definierat i initLedger fungera.

const queryResponse = väntar på stubWithInit.mockInvoke ("txID2", ["queryAllCars"]);

förvänta dig (Transform.bufferToObject (queryResponse.payload)). till.deep.eq ([

           {

               märke: ‘Toyota’,

               modell: ‘Prius’,

               färgen blå’,

               ägare: ‘Tomoko’,

               docType: ‘bil’,

               nyckel: ‘CAR0’

           },

       ])

   });

2. Testa Skapa bil

Låt oss åberopa skapa bilobjektet i ett nytt testfall. Detta är ett bra exempel eftersom det lär oss hur man skickar argument till mockInvoke-funktionaliteten. Detta test består av två komponenter. Först lägger vi till den nya bilen i blockchain-tillståndet, därefter frågas bilen för att jämföra båda objekten.

const stub = ny ChaincodeMockStub ("MyMockStub", kedjekod);

const response = väntar på stub.mockInvoke ("tx1", [‘createCar’, JSON.stringify ({

      nyckel: ‘CAR0’,

      göra: "prop1",

      modell: "prop2",

      Färg: "prop3",

      ägare: ‘ägare’

})]);

förvänta dig (response.status) .to.eql (200)

Som du kan se kan vi skicka ett helt strängat JSON-objekt till mockInvoke funktion som innehåller alla egenskaper för att skapa det nya bilobjektet. Efter att ha skapat bilen verifierar vi körningsstatusen.

Nu har bilen lagts till, vi kan fråga den igen för att använda den i vår jämförelsefunktion. Vi passerar in nyckeln till bilen vi just har skapat ‘CAR0’ och utför en djup-lika.

3. Testa privata samlingar

Okej, vi har gått in i den sista delen av den här självstudien där vi kommer att testa data insikt privata samlingar. Återigen har mockstuben ett minnesalternativ för privata samlingar så vi behöver inte starta vårt Hyperledger Fabric-nätverk.

Återigen, det första vi kommer att göra är att skicka argumenten för att skapa vår privata bil via createPrivateCar fungera.

const stub = ny ChaincodeMockStub ("MyMockStub", kedjekod);

const response = väntar på stub.mockInvoke ("tx1", [‘createPrivateCar’, JSON.stringify ({

    nyckel: ‘CAR0’,

    göra: "prop1",

    modell: "prop2",

    Färg: "prop3",

    ägare: ‘ägare’

})]);

förvänta sig (response.status) .to.eql (200);

Okej, låt oss jämföra det förväntade objektet med objektet från den privata samlingen i minnet. Stubben är tillräckligt smart för att skapa samlingen i minnet när du åberopar kedjekodsfunktionen. De stub.privateCollections har en matris med alla privata datainsamlingar och vi anger vilken samling vi vill ha och vilket objekt som ska hämtas från denna samling. Detta objekt kan matchas med det förväntade bilobjektet.

förvänta dig (Transform.bufferToObject (stub.privateCollections ["privateCarCollection"] ["CAR0"till.deep.eq ({

           ‘make’: ‘prop1’,

           ‘modell’: ‘prop2’,

           ‘färg’: ‘prop3’,

           ‘ägare’: ‘ägare’,

           ‘docType’: ‘bil’

       })

Kör alla tester

Okej, det är dags att köra våra tester igen, använd npm körtest. Om allt går bra bör du se en fin översikt över vad som hände för varje test och dess resultat. Koden ska ge 8 godkända resultat enligt nedan.

Vad lärde vi oss?

ChaincodeMockStub är verkligen användbart eftersom det gör det möjligt för en utvecklare att testa sin kedjekod utan att starta nätverket varje gång. Detta minskar utvecklingstiden eftersom han kan använda en testdriven utvecklingsstrategi (TDD) där han inte behöver starta nätverket (det tar + – 40-80 sekunder beroende på datorns specifikationer). Att komma åt privata minnessamlingar är också mycket enkelt via stub.privateCollections array. Du behöver bara några av Chais testfunktioner som djupet för att testa din kedjekod korrekt.

Kod Cheatsheet

  1. Skapa instans av kedjekod som anropar initLedger-funktionen.

väntar på stub.mockInit ("tx1", []);

  1. Anropa en normal funktion och skicka argument.

    const response = väntar på stub.mockInvoke ("tx1", [‘createCar’, JSON.stringify ({

          CarObject…

    })]);

    3. Åkalla en kedjekodsfunktion som använder privata samlingar och skicka argument.

väntar på stub.mockInvoke ("tx1", [‘createPrivateCar’, JSON.stringify ({

    CarObject…

})]);

  1. Standard svar löfte tillbaka från båda mockInit och mockInvoke:

Löfte<{

   status: nummer;

   meddelande: sträng;

   nyttolast: buffert;

}>

Ytterligare läser

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me