Consigli per verificare il livello di richiesta API nelle app iOS utilizzando NSOperations and Coredata

Question

Sviluppo un'app iOS che utilizza un'API REST. L'app iOS richiede i dati nei thread di lavoro e memorizza i risultati analizzati nei dati principali. Tutte le viste utilizzano i dati principali per visualizzare le informazioni. L'API REST cambia rapidamente e non ho alcun controllo reale sull'interfaccia.

Sto cercando consigli su come eseguire i test di integrazione per l'app il più semplice possibile. Dovrei testare contro l'API o contro i dati Mock? Ma come prendere in giro le richieste GET correttamente se è possibile creare risorse con POST o modificarle con PUT?

Quali strutture utilizzate per questo tipo di problemi? Ho suonato con Frank, che sembra carino ma è complicato a causa delle rapide modifiche dell'interfaccia utente nell'app iOS. Come testerebbe il "livello di richiesta API" nell'app? I thread di lavoro sono NSOperazioni in una coda: tutto viene creato in modo asincrono. Qualche consiglio?

Answer 1

Si consiglia vivamente di prendere in giro il server. I server scendono, il comportamento cambia e se un test fallisce implica "forse il mio codice funziona ancora", hai un problema a portata di mano, perché il tuo test non ti dice se il codice è rotto o meno, che è l'intero punto.

Quanto a come prendere in giro il server, per una prova di unità che fa questo:

first_results = list_things() 
delete_first_thing() 
results_after_delete = list_thing() 

Ho una struttura di dati finta che assomiglia a questo:

{ list_things_request : [first_results, results_after_delete], 
    delete_thing_request: [delete_thing_response] } 

E 'calettato su vostra richiesta e il valore è una matrice di risposte per tale richiesta nell'ordine in cui sono state visualizzate. Quindi puoi supportare ripetutamente la stessa richiesta (come elencare le cose) e ottenere un risultato diverso. Uso questo formato perché nella mia situazione è possibile che le mie chiamate API vengano eseguite in un ordine leggermente diverso rispetto all'ultima volta. Se i tuoi test sono più semplici, potresti riuscire a farla franca con un semplice elenco di coppie richiesta/risposta.

Nella mia unit test ho una bandiera che indica se sono in modalità "registrazione" (ovvero, parlando con un server reale e registrando questa struttura dati su disco) o se sono in modalità "riproduzione" (parlando con la struttura dati). Quando ho bisogno di lavorare con un test, "registra" le interazioni con il server e poi le riproduco.

Uso la SenTestCaseDidStartNotification poco conosciuta per tenere traccia di quale test dell'unità è in esecuzione e isolare i file di dati in modo appropriato.

L'altra cosa da tenere a mente è che l'instabilità è la radice di tutti i mali. Se hai codice che fa cose con insiemi, o ottiene la data corrente, e così via, questo tende a cambiare le richieste e le risposte, che non funzionano in uno scenario offline. Quindi stai attento con quelli.

Answer 2

(Dal momento che nessuno è intervenuto e ti ha dato una spiegazione completa) Il mio umile consiglio: fai un passo indietro, estrai la magia dell'async, considera tutto come sincronizzazione (api chiama, analisi, persistenza) e isola ogni passaggio come consumatore/produttore. Dopotutto non si vuole testare unitamente NSURLConnection, o JSONKit o qualsiasi altra cosa (dovrebbero essere stati testati se li si usa), si vuole testare il proprio codice. Il tuo codice prende un po 'di input e produce output, non consapevole del fatto che l'input era in realtà l'output generato in un thread in background da qualche parte. Puoi eseguire il test isolato tutto in sincronia.

Possiamo essere d'accordo sul fatto che alle vostre Viste non interessa come sono stati forniti i dati del modello? Se sì, prova la tua vista con oggetti finti.

Siamo d'accordo sul fatto che al vostro parser non interessa come sono stati forniti i dati? Se sì, prova il tuo parser con dati falsi.

Livello rete: lo stesso vale come descritto sopra, alla fine si otterrà un NSDictionary di intestazioni e alcuni NSData o NSString di contenuto. Non penso che vogliate testare unitamente NSURLConnection o qualsiasi terza rete di terze parti che abbiate fiducia (asihttp, afnetworking, ...?), Quindi alla fine, cosa si deve testare? Puoi simulare gli URL, richiedere intestazioni e dati POST per ogni caso d'uso che hai e configurare i casi di test per le risposte previste.

Alla fine, IMHO, si tratta di "normalizzare" fuori asyc.

Answer 3

Date un'occhiata a Nocilla

Per ulteriori informazioni, controllare this other answer a una domanda simile