2009-12-14 4 views
10

Sto provando a scegliere tra OCUnit e Google Tool Box, hai qualche preferenza, consiglierei l'uno o l'altro, perché? Sarei molto interessato a conoscere le vostre esperienze con una delle 2.Test unitario e TDD, OCUnit vs Google Tool Box

Il problema principale che ho con tutti e due è il managment di incidenti in metodi testati (es: ACCESSO BAD) Nessuno di loro è stato in grado per dirmi in quale classe si è verificato l'incidente !!!

Con Google Tool Box posso vedere quale suite di test era gestita, ma non è il caso di test (come stai dovrebbe fare quando la vostra suite di test ha 50 casi di test?)

Con OCUnit posso almeno vedere quale caso di test in quale suite di test ha causato l'incidente.

Qui è il tipo di messaggio che ho con GTB:

Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds 

Test Suite 'LogicTests' started at 2009-12-14 18:03:15 +0100 

/Users/admin/Documents/Tests/GTBTest/RunIPhoneUnitTest.sh: line 122: 688 Segmentation fault  "$TARGET_BUILD_DIR/$EXECUTABLE_PATH" -RegisterForSystemEvents 

Command /bin/sh failed with exit code 139 

posso vedere che è esso il 'LogicTests' suite di test che ha avuto origine l'incidente, ma questo è tutto.

Con OCunit qui è il messaggio per lo stesso errore:

Test Suite 'LogicTests' started at 2009-12-14 17:51:26 +0100 
Test Case '-[LogicTests testFail]' started. 
/Developer/Tools/RunPlatformUnitTests.include: line 415: 536 Segmentation fault  "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}" 

Almeno con OCUnit posso seguire ciò che banco di prova è stato in esecuzione e, infine, eseguire il debug (ma che potrebbe richiedere molto tempo senza alcun informazioni sulla classe e sul numero di linea ...)

Come si gestiscono questi problemi?

Grazie in anticipo.

PS: qui è come riprodurre il problema, è molto semplice:

basta creare una classe con un metodo che va in crash quando si chiama (il che accade tutto il tempo quando si sta facendo TDD):

- (void) crashMethod { 
NSMutableArray *crashArray; 
[crashArray addObject:[NSObject new]]; 
} 

e quindi creare un banco di prova che chiama questo metodo:

- (void) testFail { 
    ClassToTest *test = [[ClassToTest alloc] init]; 
[test crashMethod]; 
[test release]; 
} 

Grazie in anticipo, Vincent

risposta

3

Penso che andrò con GTB comunque ..

con Xcode 3.2 errori OCUnit e gli avvisi non vengono visualizzati all'interno del codice. Sembra che sia un problema noto: lhttp://osdir.com/ml/xcode-users/2009-10/msg00216.html

Con GTB funziona correttamente. Non posso crederci, ma sembra che GTB sia meglio integrato con le versioni più recenti di xCode rispetto a OCUnit ....

Il debug di test di unità non richiede nulla, funziona alla grande sin dall'inizio. (Con Xcode avete bisogno di un sacco di impostazioni: http://chanson.livejournal.com/119578.html

Con GTB è possibile eseguire i test sul dispositivo e si dispone di strumenti per il test dell'interfaccia utente (sembra è possibile creare una gerarchia UIView falso e poi confrontarlo con quello che hai in fase di esecuzione) Sono scettico riguardo ai test automatici dell'interfaccia utente (costoso e difficile da mantenere) ma questa è una bella funzionalità!

http://code.google.com/p/google-toolbox-for-mac/wiki/CodeVerificationAndUnitTesting

+0

@ user142764: come si fa a test di unità di debug con GTB allora? Sicuramente hai ancora bisogno di un eseguibile personalizzato? – jkp

+0

No, questo è ciò che è fantastico con GTB: dal momento che si utilizza un obiettivo normale per eseguire i test, è possibile eseguire il debug di esso! Basta scrivere un test, inserire un breakpoint, quindi eseguire Run-> Debug dal menu ed eccolo: si sta eseguendo il debug del test passo per passo. – user142764

0

proposito il caso di prova di Google Toolbox ora di stampare i messaggi in caso qualcuno ha iniziato chiedevo ;-)