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 interrotto l'API, vogliamo avere una sorta di software automatico per testarle continuamente. Come affrontare questo?
Risposta breve: hai bisogno di una suite di test per un'API del fornitore di terze parti, quindi dovrai svilupparne una.
Non aspettarti che qualcun altro lo faccia per te e non aspettarti una "bacchetta magica" per generare automaticamente i test giusti.
Alcune cose che potresti provare in aggiunta:
Se queste cose funzionano o meno dipende da chi è il tuo fornitore e che tipo di API hai in mente. Un'API che produce un output analizzabile come i file è molto più facile da test 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.
Sulla base del fraseggio del poster, è più che un semplice test, IMO. Dopo aver scritto il test dell'unità per l'API e verificato che tutto funzioni come previsto, è necessario monitorare le API di terze parti in modo da rilevare eventuali 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 quanto test sono stati effettuati sull'API o quando / se cambia.
(Dichiarazione di non responsabilità: nomi di prodotti utilizzati qui) Se si utilizza soapUI per scrivere i propri test API, tali test possono essere riutilizzati in AlertSite come monitor operativo per assicurarsi che l'API continui a funzionare come previsto. Se fallisce il test, puoi essere avvisato prima che i tuoi utenti ti chiamino e si lamenta che la tua app non funziona.
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 contro il contratto pubblico dell'API. I test non dovrebbero essere scritti rispetto ai dettagli di implementazione interna anche se il codice sorgente per l'API è disponibile. Questo tipo di test di apprendimento ha due scopi:
Ci sono 2 approcci per questo problema ...
la tua app è in produzione in tempo reale con traffico utente reale:
se hai un'app in produzione con traffico live e dipende da una API esterna non hai altra scelta che monitorare da vicino e avere soglie buone da sapere il più velocemente possibile quando la API esterna apporta le modifiche senza notifica.
dovresti sempre tener conto che:
la tua app è un'installazione e ha versioni / versioni pianificate:
in questo caso hai un periodo di prova per fallire ... l'utente dal vivo non viene immediatamente influenzato dalle modifiche alle API esterne.
secondo me questo è un compito più facile. scrivere un test (test completo end-to-end) che rende reali transazioni / http / richieste all'applicazione che invocano l'API esterna e verificare che non vi siano errori. nessun test-kit non prende in giro la transazione reale.
una volta completata questa attività, puoi scegliere di eseguirla ogni 24 ore, 1 minuto ecc.
buone pratiche:
Strumenti
Leggi altre domande sui tag testing integration-tests api continuous-integration rest