Mocks, stubs, fakes és emulators: api-hívások tesztelése kódügynökökkel

Amikor a kód meghív egy API-t, szüksége van arra, hogy tesztelhesse anélkül, hogy meg kellene várnia, amíg a valódi API meghibásodik. Ötféle stand-in közül választhat. A felhasználók lazán használják a neveket, ezért a cikk az alábbi módon használja őket:

  • Stub: a HTTP-ügyfél vagy az SDK-hívás folyamaton belüli helyettesítője, amely egy előre meghatározott választ ad vissza. Gyors és megismételhető, és teszteli az Ön által írt válasz mögötti logikát.
  • Mock: egy stub, amely azt is rögzíti, hogyan hívta meg a kód, így a teszt ellenőrizheti a hívásokat. Egészen a stubig ér.
  • Álkiszolgáló: egy kisméretű, működő kiszolgáló, amely gyakran memóriában fut, és amelyet az alkalmazás HTTP-n keresztül hív meg a valódi API helyett. Teszteli a HTTP-klienst, de az alkalmazást az URL-címére kell mutatnia.
  • Emulátor: a szolgáltatás helyi verziója, amelyet általában a szolgáltatás tulajdonosa tett közzé, és a támogatott műveletek esetében ugyanúgy viselkedik, mint a valódi szolgáltatás. Ellenőrizze, hogy milyen korlátokra és meghibásodásokra vonatkozik, mielőtt a hibák kezelésében erre támaszkodik.
  • Beékelődő proxy: az alkalmazás és az API közötti hálózaton helyezkedik el. Az alkalmazás meghívja a valódi URL-címet, és a proxy átadja a kéréseket, vagy közülük néhányat az Ön által megadott válasszal válaszol meg. Az alkalmazásnak a proxyn keresztül kell elküldenie a forgalmat, és HTTPS esetén meg kell bíznia a proxy tanúsítványában.

API-t meghívó kód tesztelése

Approach Mit tesztel? Amire szüksége van Pont amikor
Stub vagy mock Az adott válasz logikája Az Ön tesztkeretrendszere Az egységtesztekben tesztelheti az üzleti logikát, a szintaktikai elemzést és a hibaágakat
Hamis szerver A HTTP-ügyfél és a szerializálás Alap URL-beállítás vagy konfigurációs kapcsoló az alkalmazásban Az API még nem létezik, vagy stabil háttérrendszerre van szüksége a felhasználói felületen végzett munkához
Emulator A támogatott műveletek valós szolgáltatáshoz közeli viselkedése Másik végpont vagy kapcsolati karakterlánc A szolgáltatás tulajdonosa szállít egyet, ön pedig offline fejleszt.
Valós API tesztfiókkal Az igazi Bejelentkezési adatok, kvóta és egyenleg Ellenőrizze a fő elérési utat végponttól végpontig
Beékelődő proxy A futó alkalmazásod valós URL-címeken, beleértve az SDK újrapróbálkozásait és a válaszfejléceket Proxybeállítások és tanúsítványmegbízhatóság Az alkalmazás módosítása nélkül tesztelheti a hibákat, a korlátokat és a késleltetést

Ezek közül többre van szüksége. A stubok gyorsan futnak az egységtesztjeid. A proxy megmutatja, hogy mit csinál az egész alkalmazás, ha a valódi API rendellenesen működik. Arról, hogyan illeszkedik egymáshoz a kettő, további információt a Dev Proxy kontra egységtesztek című témakörben talál.

Milyen kódolási ügynökök épülnek fel?

Amikor egy kódoló ügynököt kér fel, hogy kezelje az alkalmazás API-hibáit, és mutassa, hogy működik, az egy helyettesítőt választ Önnek. Tudni akartuk, melyiket, ezért 3 kódolási ügynökkel (210 futtatás) futtattunk egy tesztet. A feladatok olyan kifejezéseket használtak, mint a "sebességkorlátozás megfelelő kezelése és annak megmutatása, hogy működik", "ellenőrizze anélkül, hogy pénzt költene valódi API-hívásokra", és "futtassa ezt OpenAI-kulcs vagy internetkapcsolat nélkül".

  • A 140 futtatás 76%-ában, amely működő kódot kért, az ügynök kézzel idézte elő a hibát: fetch stubok, httpx.MockTransport, vagy egy eldobható HTTP-kiszolgáló.
  • A 105-ből 61-ben olyan alkalmazások futnak, amelyek GitHub, OpenAI vagy időjárási API-t hívnak meg, az ügynök egy alap URL-címet vagy konfigurációs kapcsolót adott hozzá az alkalmazáshoz, hogy elérhesse a hamisját.
  • A 75-ös verzióban, ahol a valódi API elérhető volt, és a parancssor nem zárta ki, 0 tesztelte az alkalmazást a valódi API URL-címén.

A stubok ésszerű választás az egységtesztekhez. A hiány az, amit kihagynak. Az ügynök stubja az ügynök által várt hibát adja vissza, amely nem feltétlenül egyezik az API által küldött hibával. És a hozzáadott kapcsoló az alkalmazásban lehetővé tette a hamis hajók elérését.

Hogyan dolgozhat az ügynök tesztjeivel

  • Tartsa meg a logikához tartozó stubokat. Gyorsak, és tesztelik az agent által írt ágakat.
  • Kérje le a tényleges hibaformátumot. Kérje meg az ügynököt, hogy minden szimulált hibát a szolgáltató dokumentált állapotkódjaira, fejléceire és törzsmezőire alapozza. Egy csupasz 429 nem teszteli, hogy az alkalmazás beolvassa-e a retry-after elemet, vagy megkülönbözteti-e a számlázási hibát a sebességkorláttól.
  • Tekintse át a tesztekhez hozzáadott kapcsolókat. Ha az ügynök csak azért ad hozzá alap URL-beállítást, hogy a tesztek elérjenek egy hamis végpontot, döntse el, hogy szüksége van-e erre a beállításra az éles kódban.
  • Futtassa az alkalmazást egyszer valós URL-címeken, szimulált hibák mellett. Kiadás előtt ellenőrizze, hogy a futó alkalmazás, az SDK és az újrapróbálkozási szabályzat mit tesz az API saját hibáival. Ha lépésről lépésre szeretné áttekinteni az ügynök hibakezelését, olvassa el a kódolási ügynök által írt hibakezelés ellenőrzésének módját.

Próbálja ki az alkalmazásában

Dev Proxy egy elfogó proxy fejlesztéshez. Visszaadja az alkalmazás által már hívott URL-címekre adott válaszokat, és nem módosítja az alkalmazás kódját. Engedélyezze a MockResponsePlugin beépülő modult a konfigurációban, devproxyrc.json:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "MockResponsePlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "mocksPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "mocksPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.schema.json",
    "mocksFile": "mocks.json"
  }
}

Ezután adja meg a választ a(z) mocks.json elemben. Ez az előrejelzési végpont esetén Retry-After fejléccel 503 értéket ad vissza:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.mocksfile.schema.json",
  "mocks": [
    {
      "request": {
        "url": "https://api.contoso.com/v1/forecast*",
        "method": "GET"
      },
      "response": {
        "statusCode": 503,
        "headers": [
          {
            "name": "Retry-After",
            "value": "10"
          }
        ],
        "body": {
          "error": "Service unavailable"
        }
      }
    }
  ]
}

Indítsa el a Dev Proxyt, és futtassa az alkalmazást a szokásos módon:

devproxy --config-file devproxyrc.json

A mocknak nem megfelelő kérések a valódi API-ra kerülnek. Ha olyan háttérrendszerre van szüksége, amely még nem létezik, a CrudApiPlugin egy CRUD API-t szimulál memóriabeli adatokkal. Ha a kérések egy részét nem minden alkalommal, hanem véletlenszerűen szeretné sikertelennek jelölni, olvassa el az alkalmazás tesztelése véletlenszerű hibákkal című témakört. A Dev Proxy telepítéséhez lásd: Dev Proxy beállítása.

További lépések

Szimulált válaszok

Lásd még

  • Utolsó frissítés időpontja: