Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando il codice chiama un'API, è necessario un modo per testarlo senza aspettare che l'API reale vada in errore. Hai 5 tipi di stand-in tra cui scegliere. Le persone usano i nomi in modo generico, quindi ecco come questo articolo li usa:
- Stub: sostituzione in-process per il client HTTP o la chiamata SDK che restituisce una risposta predefinita. È veloce e ripetibile e mette alla prova la logica della risposta che hai scritto.
- Mock: uno stub che registra anche il modo in cui il codice lo ha chiamato, in modo che il test possa controllare le chiamate. Arriva fino a uno stub.
- Server falso: un piccolo server funzionante, spesso in memoria, che l'app chiama su HTTP invece dell'API reale. Mette alla prova il client HTTP, ma è necessario puntare l'app al relativo URL.
- Emulatore: una versione locale di un servizio, in genere pubblicata dal proprietario del servizio, che si comporta come quella reale per le operazioni supportate. Verificare quali limiti e guasti vengono coperti prima di basarsi su di esso per la gestione degli errori.
- Proxy di intercettazione: si trova nella rete tra l'app e l'API. L'app chiama l'URL reale e il proxy passa le richieste o risponde ad alcune di esse con la risposta definita. L'app deve inviare il traffico attraverso il proxy e, per HTTPS, considerare attendibile il certificato del proxy.
Come testare il codice che chiama un'API
| Avvicinarsi | Che cosa testa | Cosa serve | Giusto quando |
|---|---|---|---|
| Stub or mock | La tua logica per una risposta specifica | Il tuo framework di test | Si verificano la logica di business, il parsing e i percorsi di errore nei test unitari |
| Server fittizio | Il tuo client HTTP e la serializzazione | Impostazione o opzione di configurazione dell'URL di base nell'app | L'API non esiste ancora, oppure è necessario un backend stabile per lavorare sull'interfaccia utente |
| Emulatore | Comportamento vicino al servizio reale per le operazioni supportate | Un endpoint o una stringa di connessione diversi | Il proprietario del servizio ne spedisce uno e tu sviluppi offline |
| API reale con un account di test | L'originale | Credenziali, quota e denaro | Verificare il percorso principale dall'inizio alla fine |
| Proxy di intercettazione | La tua app in esecuzione su URL reali, inclusi i tentativi dell'SDK e le intestazioni di risposta | Impostazioni proxy e attendibilità del certificato | Testi errori, limiti e latenza senza modificare l'app |
Sono necessari più di 1 di questi. Gli stub rendono rapidi i test unitari. Un proxy mostra cosa fa l'intera app quando l'API reale si comporta in modo errato. Per altre informazioni su come i 2 funzionano insieme, vedere Dev Proxy vs unit test.
Cosa creano gli agenti di coding
Quando chiedi a un agente di codifica di gestire gli errori dell'API e di mostrare che funziona, seleziona uno stand-in per te. Volevamo sapere quale dei tre fosse il migliore, quindi abbiamo eseguito un test con 3 agenti di programmazione (210 esecuzioni). Le attività utilizzavano formulazioni come "gestire correttamente il rate limiting e dimostrarmi che funziona", "verificarlo senza spendere denaro in chiamate API reali" e "eseguirlo senza una chiave OpenAI o una connessione a Internet".
- Nel 76% delle 140 esecuzioni che hanno richiesto codice funzionante, l'agente ha ricreato manualmente il caso di errore: stub di fetch,
httpx.MockTransport, oppure un server HTTP temporaneo. - In 61 delle 105 esecuzioni su app che chiamano GitHub, OpenAI o un'API meteo, l'agente ha aggiunto un URL di base o un commutatore di configurazione all'app in modo che potesse raggiungere il servizio fittizio.
- Nelle 75 esecuzioni in cui era disponibile l'API reale e il prompt non lo escludeva, in 0 casi è stata testata l'app sull'URL dell'API reale.
Gli stub sono una scelta ragionevole per gli unit test. Il divario è quello che lasciano fuori. Lo stub dell'agente restituisce l'errore previsto dall'agente, che potrebbe non corrispondere a quello inviato dall'API. E il selettore che ha aggiunto per accedere ai mock con la tua app.
Come lavorare con i test del tuo agente
- Mantieni gli stub per la tua logica. Sono veloci e testano i branch che l'agente ha scritto.
- Richiedi il formato dell'errore effettivo. Chiedi all'agente di basare ogni errore simulato sui codici di stato, le intestazioni e i campi del corpo documentati dal provider. Un semplice 429 non verifica che l'app legga
retry-aftero distingua un errore di fatturazione da una limitazione della frequenza. - Interruttori di revisione aggiunti per i test. Se l'agente aggiunge un'impostazione URL di base solo in modo che i test possano raggiungere un mock, decidi se vuoi questa impostazione nel codice di produzione.
- Eseguire l'app inizialmente sugli URL reali con errori simulati. Prima di rilasciare, verificare come l'app in esecuzione, il relativo SDK e i criteri di ripetizione dei tentativi gestiscono gli errori dell'API. Per esaminare la gestione degli errori dell'agente in modo dettagliato, vedere Come verificare la gestione degli errori che il tuo agente di coding ha scritto.
Provalo nella tua app
Dev Proxy è un proxy di intercettazione per lo sviluppo. Restituisce le risposte definite per gli URL che la tua app chiama già, senza modifiche al codice dell'app. Abilita MockResponsePlugin nella tua configurazione, 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"
}
}
Definire quindi la risposta in mocks.json. Questo restituisce 503 con un'intestazione Retry-After per l'endpoint di previsione:
{
"$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"
}
}
}
]
}
Avviare Dev Proxy ed eseguire l'app come di consueto:
devproxy --config-file devproxyrc.json
Le richieste che non corrispondono a un mock passano all'API reale. Quando è necessario un back-end che non esiste ancora, CrudApiPlugin simula un'API CRUD con dati in memoria. Per far fallire una parte delle richieste in modo casuale anziché ogni volta, vedi Testare l'app con errori casuali. Per installare Dev Proxy, vedere Configurare Dev Proxy.