Test riga unità di comando iPhone (e I/O file)

Question

La domanda breve è: Come posso ottenere operazioni di file iPhone (obiettivo-c) per funzionare correttamente da una riga di comando Test unità?

La lunga domanda, con spiegazione: Questo alla fine diventerà uno script per eseguire building/testing automatici per la build del mio iPhone, tramite un'istanza di Hudson. Seguendo il link di makdad su this, la domanda SO mi ha permesso di eseguire i test di unità dalla riga di comando (semi) con successo.

Tuttavia, uno dei miei test ha esito negativo. Il test chiamerebbe una classe Caching Service per salvare un file, quindi provare a recuperarlo. tuttavia, file di I/O sembra non funzionare durante l'esecuzione dei test dalla riga di comando :(.

di rinvio, in esecuzione i test di unità attraverso i risultati Xcode GUI in nessuna di tali errori.

Sto usando NSFileHandle le chiamate di metodo per ottenere le maniglie per la scrittura. in caso di ritorno pari a zero, viene creato il file usando

[[NSFileManager defaultManager] createFileAtPath:filePath contents:nil attributes:nil]; 

ho pensato che potrebbe avere a che fare con gli spazi nel percorso della directory cache del simulatore. sono sulla strada giusta ? se sì, come potrei rettificare questo?

Si noti inoltre che il simulatore deve essere NON già in esecuzione affinché funzioni, il simulatore viene avviato a livello di programmazione e non visualizza una GUI. se è in esecuzione, la generazione della riga di comando ha esito negativo.

Answer 1

Primo: 'il simulatore ha bisogno di non essere in esecuzione già in ordine per questo lavoro'
ho i miei test in esecuzione nel terminale e non importa se il simulatore è acceso.

Forse alcune impostazioni di generazione da osservare sono: TEST_HOST e BUNDLE_LOADER. Li lascio vuoti nel mio xcodeproj.
Nota: Uso anche Hudson con rapporti di test e copertura del codice.

Secondo:
ho sperimentato fallimenti nei test terminali e applicazioni con percorsi di carico. Questo era correlato al modello Core Data che viene caricato da una risorsa.
La soluzione era quella di caricare il file da URL invece di un percorso:

[[NSBundle bundleForClass:[self class]] URLForResource:....]; 

Non posso assicurare che questo si riferisce allo stesso problema tuo incontrando con la NSFileManager, ma posso solo immaginare che NSBundle fa uso del NSFileManager . (Quindi questo può essere correlato)

Terzo:
Non fare i test dipende di I/O.
Trovo che questo non sia lo scopo di un test unitario. Tale test potrebbe non basarsi su un filesystem, database, connessione di rete, ecc.

Creare una classe di astrazione del file system che si prende in giro durante l'esecuzione dei test.
In questo modo l'implementazione è solo in un punto che si basa sul file system effettivo, che è possibile sostituire durante il test.

Hai solo bisogno di un test per verificare che l'astrazione.

Sommario

• Il primo migliorerà la vostra configurazione di prova.
• Il secondo si spera che risolva il problema del test.
• Il terzo riduce l'occorrenza del problema e migliora il codice.

Spero che questo sia stato utile.