Test di un'API esterna in stato beta

I'd like to write test to ensure my code is working. Unit tests are already done for my own code. But the API itself isn't tested, because it would violate the first rule of FIRST (Fast tests). If I test the API requests/responses 'live' (they have a sandbox version of the API), tests take around 7 seconds for themselves. That's a long time.

Sono completamente d'accordo sul fatto che aggiungere 7 secondi ai test delle unità non è l'ideale, ma anche se fossero 7 microsecondi, non dovresti comunque testare l'API con i test unitari nel tuo codice. Non hai bisogno di testare l'API ogni volta che apporti una modifica al tuo codice - e devi testarlo anche se non apporti modifiche al tuo codice per un mese: devi testarlo ogni volta che fanno cambia al loro codice.

Ovviamente, non sai quanto spesso lo fanno, quindi suggerisco di eseguire il test automaticamente una volta ogni ora / giorno / settimana, a seconda di quanto spesso ti aspetti dei cambiamenti.

Certo, se sia una buona idea avere effettivamente quei test è discutibile. Personalmente, ritengo che avere qualche assegno di buon senso abbia senso, soprattutto per i servizi instabili in cui qualcuno può apportare modifiche senza nemmeno cambiare la versione della patch e quindi devi investigare per ore finché non te ne accorgi - ma sto divagando: anche assumendo le migliori pratiche, potresti aver interpretato erroneamente l'API e una modifica che non avrebbe influito sul normale utilizzo di esso interrompe il tuo codice.

Onestamente, l'API che chiami dovrebbe avere uno schema di controllo delle versioni. IE, un'API con cui ho lavorato in passato era formattata link , ma erano in prova con una v2 che viveva a < a href="http://clientaddress.com/v2/endpoints"> link . Mentre volevamo utilizzare la nuova API appena possibile, abbiamo potuto testare solo contro v1 (la versione stabile) per garantire che le cose funzionassero. Detto questo, abbiamo risolto il problema di sovraccaricare metodi / chiamate / qualsiasi altra cosa per accettare i nuovi oggetti dalla v2 api, quindi chiamare i nostri metodi v1-formattati usando questi oggetti. In questo modo, siamo stati in grado di testare un prodotto "incompleto" assicurandoci che la logica sulla nostra parte fosse corretta.

L'altra opzione, anche se è una sorta di "imbroglio" poiché (penso?) non vuoi mai testare con i mock, è creare una API fittizia localmente che restituisca un oggetto o degli oggetti pre-impostati nel formato che tu ci si aspetta dall'API del client e questo metodo deve essere quello che viene chiamato ogni volta che si desidera parlare con l'API del client. In questo modo, puoi provare che il tuo codice funziona con oggetti finti e quando sei pronto per testare l'API del client nella sua forma definitiva, puoi modificare questo metodo per andare al reale con il minimo sforzo.