OCUnit test di un framework incorporato

Question

UPDATE: alla fine ho rinunciato e ho aggiunto GHUnit al mio progetto. Ho iniziato a lavorare con GHUnit in pochi minuti.

UPDATE: È possibile scaricare il progetto Xcode qui: http://github.com/d11wtq/Cioccolata

Ho aggiunto un target unit test al mio progetto Xcode, ma non riesce a trovare il mio quadro, quando si costruisce, dicendo:

Test.octest could not be loaded because a link error occurred. It is likely that dyld cannot locate a framework framework or library that the the test bundle was linked against, possibly because the framework or library had an incorrect install path at link time.

Il mio framework (l'obiettivo principale del progetto) è progettato per essere incorporato e quindi ha un percorso di installazione di @executable_path/../Frameworks.

Ho contrassegnato il framework come dipendenza diretta del target di test e l'ho aggiunto alla fase di costruzione "Link Binary with Libraries".

Inoltre ho aggiunto un primo passaggio (dopo aver generato la dipendenza) di "Copia file" che copia semplicemente il framework nella directory Framework dei bundle dell'unità di test.

Qualcuno ha esperienza in questo? Non sono sicuro di cosa mi sia perso.

MODIFICA | Sono abbastanza sicuro che non dovrei, dal momento che un framework non è eseguibile, ma non ho impostato "Test Host" e "Bundle Loader". Questo dovrebbe (a mio modo di vedere) tutto ok perché il bundle di test è collegato al framework e lo caricherà proprio come qualsiasi altro bundle.

MODIFICA | Penso di essere quasi arrivato. Ho letto il seguente articolo che detta l'uso di @rpath invece di @executable_path.

http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/

In questo caso ha perfettamente senso dal momento che il fascio di prova OCUnit NON è un eseguibile, si tratta di un vecchio fascio pianura, quindi @executable_path non è compatibile. Così ora il mio framework ha la sua directory di installazione impostata su @rpath e la destinazione Test ha i suoi percorsi di ricerca di runtime (rpath) definiti come la directory di compilazione. Questo mi evita di dover copiare il framework nel bundle di test e significa che nel complesso la struttura risultante è di natura molto più flessibile poiché può vivere ovunque.

Ora, mi rendo anche conto che I deve impostare il Caricatore fascio sulla destinazione Test, quindi questo è ora impostato sul percorso del file binario.

Posso creare il target di test e posso # importare classi dal framework, senza errori. Ma non appena cerco di istanziare una classe dal quadro ottengo il seguente errore:

/Developer/Tools/RunPlatformUnitTests.include:412: note: Started tests for architectures 'i386' /Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests for architecture 'i386' (GC OFF) objc[50676]: GC: forcing GC OFF because OBJC_DISABLE_GC is set Test Suite '/Users/chris/Projects/Mac/Cioccolata/build/Debug/Test.octest(Tests)' started at 2010-05-21 12:53:00 +1000 Test Suite 'CTRequestTest' started at 2010-05-21 12:53:00 +1000 Test Case '-[CTRequestTest testNothing]' started. /Developer/Tools/RunPlatformUnitTests.include: line 415: 50676 Bus error "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}" /Developer/Tools/RunPlatformUnitTests.include:451: error: Test rig '/Developer/Tools/otest' exited abnormally with code 138 (it may have crashed). Command /bin/sh failed with exit code 1

Il mio metodo di prova non fa altro che assegnare e successivamente rilasciare una classe HelloWorld ho creato per aiutare il debug di questa configurazione:

- (void)testNothing { 
    CTHelloWorld *h = [[CTHelloWorld alloc] init]; 
    [h release]; 
} 

Se sostituisco queste righe di codice con un STAssertTrue(YES, @"Testing nothing"); l'errore va via, anche se la classe è ancora in fase di importazione.

Answer 1

Poiché nessun altro ha risposto a questa domanda, finirò dicendo che SenTestingKit mi ha davvero impressionato con la complessità (e la bruttezza) del setup per i miei bisogni. Consiglio vivamente GHUnit che viene eseguito in un'interfaccia utente (o sulla riga di comando se preferisci) e supporta l'utilizzo di gdb out of the box. Mi ci sono voluti pochi minuti per scaricare e utilizzare GHUnit nel mio progetto.

È anche bello. Apple dovrebbe spedirlo con Xcode invece di SenTestingKit IMHO.

Answer 2

Potresti avere un po 'di fortuna con il seguente article, in particolare l'aggiunta di DYLD_FRAMEWORK_PATH e DYLD_LIBRARY_PATH al tuo eseguibile potrebbe aiutare.

Answer 3

Mi è successo un paio di volte. So che sei passato a GHUnit, ma nel caso qualcuno fosse interessato: dopo aver girato per un lungo periodo ho capito che Xcode non aggiungeva semplicemente le classi di codice (file .m) nella parte Compile del target, ma in la parte delle risorse di copia del target. Spostarlo nel posto giusto ha risolto il problema.

Answer 4

Ok, così anche ho combattuto con questo, e qui è quello che ho trovato per essere la semplice soluzione al problema:

1. Crea la tua applicazione/quadro
2. Creare il vostro pacco di prova "obiettivo supplementare ", non impostare una dipendenza sul tuo principale
3. Trascina i file che vuoi testare dalle tue classi alle" fonti di compilazione "del target del gruppo di test
4. Crea i casi di test, aggiungendoli solo al target del gruppo di test
5. target di test di compilazione, test eseguito.

Nota: ciò significa che è sufficiente compilare il target del gruppo di test quando si desidera eseguire i test. Ideale, no; funziona, si.

Apple lo automatizza e lo fa funzionare correttamente, fuori dalla scatola.

Answer 5

Sono d'accordo con le raccomandazioni per GHUnit, è assolutamente incredibile!

Tuttavia, ho passato a utilizzare OCTest dopo che Apple l'ha integrato in xCode4, quindi sto arrancando tra i problemi.

Il problema di collegamento riportato qui si è verificato per me dopo aver aggiunto nuovi file al progetto. Questi includono ViewControllers e xibs ma i file sono stati contrassegnati in xcode sia per l'applicazione che per il target di test. Ho scoperto i file esaminando il pacchetto OCTest nella directory dei dati derivati. ~/Libreria/Sviluppatore/Xcode/DerivedData/Fare clic con il tasto destro e scegliere "Mostra contenuto pacchetto" dal Finder. Cerca cose che non ci appartengono, cioè: classi e risorse dell'applicazione. La rimozione di questi file da "Compile Sources" o "Copy Bundle Resources" ha corretto l'errore di collegamento.

Answer 6

Ho avuto lo stesso problema ma con il quadro di prova dell'unità Kiwi. Il mio problema era che "Test Host" non era impostato in Build Settings. Quando l'ho impostato su $ (BUNDLE_LOADER), tutto ha funzionato perfettamente. Verificato utilizzando Xcode 4.5.2 iOS SDK 6.0.