Come eseguire test API esterni (blackbox)

14

Supponiamo che tu stia utilizzando le API di un fornitore, come assicurarti che la loro API funzioni come previsto?

La mia preoccupazione principale è che a volte il fornitore ha spinto le modifiche al proprio codice e ha rotto l'API, vogliamo avere una sorta di software automatico per testarli continuamente. Come gestirlo?

— user34401
fonte

A seconda della lingua, potrebbero esserci degli strumenti che possono aiutare (sto pensando a Pex per le librerie / API C #).

— Steven Evers,

10

Risposta breve: è necessaria una suite di test per un'API di fornitori di terze parti, quindi è necessario svilupparne una.

Non aspettarti che altri lo facciano per te e non aspettarti un "proiettile magico" per generare automaticamente i test giusti.

Alcune cose che potresti provare ulteriormente:

chiedere al venditore se forniscono un elenco di "modifiche non consentite" per ogni nuova versione
chiedi loro come si preoccupano della compatibilità API / informali che questa è una funzione importante per te
controlla se l'API fornisce hook di test specifici, output di registrazione o qualcosa del genere per parti che non possono essere testate facilmente neanche
avvolgere le chiamate API importanti con il proprio codice di registrazione, scrivendo l'input e l'output correlato dell'API in un file di registro, questo renderà più semplice il debug delle cose se succede qualcosa di inaspettato
aggiungere affermazioni alle chiamate API per verificare pre e postcondizioni, quindi se una nuova versione dell'API mostra un comportamento imprevisto all'interno dell'applicazione, si viene informati in anticipo da un messaggio di errore

Se queste cose funzionano o no dipende da chi è il tuo fornitore e dal tipo di API che hai in mente. Un'API che produce alcuni output ispezionabili come i file è molto più facile da testare rispetto a un'API che controlla alcuni dispositivi fisici in cui è necessario osservare il comportamento della cosa per decidere se la chiamata API ha avuto esito positivo o meno.

— Doc Brown
fonte

Sono totalmente d'accordo, ma mi sembra che l'interrogante non abbia esperienza con le unità di test e non conosca lo schema di lavoro con esse. Voglio dire: trova punti critici, scrivi unità di test, esegui tutti i test, debug, durante il debug trova nuovi punti critici, scrivi nuove unità, ripeti gli ultimi 4 passaggi dopo ogni modifica dell'API.

— Gangnus,

@Gangnus: IMHO l'OP non ci ha raccontato nulla delle sue precedenti esperienze con i test unitari. Se ha problemi con questo, sono sicuro che sa fare una domanda più specifica. Inoltre, l'argomento qui non è "unit test", ma "test di integrazione automatizzati". Questi richiedono in genere uno schema diverso rispetto, ad esempio, al test di unità in modo TDD.

— Doc Brown,

Sì, non l'aveva detto. Ma se chiede "come assicurarsi che la loro API funzioni come previsto" senza menzionare le unità di test, "mi sembra", che non le conosce. Per quanto riguarda i test di integrazione automatizzata, non li conosce nemmeno con maggiore probabilità, ha menzionato semplicemente "una sorta di software automatico". Stai aspettando dalle persone le stesse tue conoscenze, ma in questi temi il 99% dei programmatori (incluso me) ne conosce molto meno. e il 90% molto molto meno.

— Gangnus,

0

Basato sul fraseggio del poster, è più di un semplice test, IMO. Dopo aver scritto il test unitario per l'API e aver verificato che tutto funzioni come previsto, è necessario monitorare le API di terze parti in modo da rilevare i problemi prima che gli utenti lo facciano. Questo è il vero rischio con le API di terze parti: non è il tuo codice e non hai alcun controllo su quanti test sono stati eseguiti sull'API o quando / se cambia.

(Dichiarazione di non responsabilità: nomi di prodotti utilizzati qui) Se si utilizza soapUI per scrivere i test API, tali test possono essere riutilizzati in AlertSite come monitor operativo per assicurarsi che l'API continui a funzionare come previsto. Se il test fallisce, puoi essere avvisato prima che gli utenti ti chiamino e lamentano che l'app non funziona.

— Lorinda Brandon
fonte

0

Implementa test di apprendimento per la tua area di interesse (funzionalità che prevedi di utilizzare). I test di apprendimento sono test di integrazione scritti dallo sviluppatore in base al contratto pubblico dell'API. I test non devono essere scritti in base ai dettagli di implementazione interni anche se è disponibile il codice sorgente per l'API. Questo tipo di test di apprendimento ha due scopi:

Migliora notevolmente la comprensione dell'API di terze parti.
I test aiutano a verificare se la nuova versione rivendicata è effettivamente compatibile con le versioni precedenti.

— Anand Patel
fonte

0

Esistono 2 approcci per questo problema ...

la tua app è in produzione dal vivo con traffico reale dell'utente:

se hai un'app in produzione che ha traffico in tempo reale e dipende da un'API esterna non hai altra scelta che monitorare da vicino e avere buone soglie da sapere il più velocemente possibile quando l'API esterna apporta modifiche senza preavviso.

dovresti sempre tenere presente che:

il cambiamento di api nel tempo
il fornitore API può avere dei bug
I kit di test dei fornitori di api possono avere bug o non coprire completamente tutte le funzionalità di produzione di api

l'app è un'installazione e ha versioni / versioni pianificate:

in questo caso hai un periodo di tolleranza per fallire ... l'utente live non viene immediatamente influenzato dalle modifiche esterne alla rottura dell'API.

secondo me questo è un compito più semplice. scrivere un test (test completo end-to-end) che esegua transazioni / http / richieste reali sull'applicazione che invochi l'API esterno e controlli che non vi siano errori. nessun test-kit nessuna simulazione reale di transazione.

al termine di questa attività è possibile scegliere di eseguirlo ogni 24 ore, 1 minuto ecc ...

buone abitudini:

automatizza tutto
avere una persona che è possibile contattare rapidamente dal fornitore dell'API esterno
non fidarti ciecamente del venditore testare tutto
falliscono velocemente - se il tuo servizio dipende in larga misura dall'API esterna, non interrompere il servizio. falliscono velocemente e restituiscono i messaggi di errore corretti

utensili:

monitoraggio dell'applicazione live: hyperic new-relic
api testing: apimetrics runscope soapui

— Nimrod007
fonte