Prueba de la unidad y TDD, OCUnit vs Caja de Herramientas Google

Question

Estoy tratando de elegir entre OCUnit y Caja de Herramientas Google, ¿tiene alguna preferencia, recomendaría uno o el otro, ¿por qué? estaría muy interesado en escuchar acerca de sus experiencias con cualquiera de los 2.

El principal problema que tengo con ambos es la gerencia de los accidentes en los métodos ensayados (ex: ACCESO BAD) ninguno de ellos fue capaz para decirme en qué clase ocurrió el accidente !!!

con la caja de herramientas Google puedo ver qué conjunto de pruebas estaba siendo dirigido pero no es el caso de prueba (¿cómo se supone que debe hacer cuando el banco de pruebas tiene 50 casos de prueba?)

Con OCUnit al menos puedo ver qué caso de prueba en qué suite de prueba causó el bloqueo.

Aquí es el tipo de mensaje que tengo 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 

puedo ver que es el conjunto de pruebas que LogicTests '' que originaron el accidente, pero eso es todo.

Con OCunit aquí es el mensaje para el mismo error:

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}" 

Al menos con OCUnit i puede realizar un seguimiento de lo que caso de prueba se está ejecutando y, finalmente, depurarlo (pero que podría tomar un tiempo muy largo sin ningún la clase y la información de número de línea ...)

¿cómo hacer frente a estos problemas?

Gracias de antemano.

PS: aquí es cómo reproducir el problema, es muy simple:

Basta con crear una clase con un método que se bloquea cuando se llama (que pasa todo el tiempo cuando estás haciendo TDD):

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

y luego crear un caso de prueba que llama a este método:

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

gracias de antemano, Vicente

Answer 1

Creo que voy a ir con GTB todos modos ..

Con xCode 3.2 OCUnit errores y advertencias no aparecen en el código. Parece que es un problema conocido: lhttp://osdir.com/ml/xcode-users/2009-10/msg00216.html

Con GTB funciona bien. No puedo creerlo pero parece que GTB está mejor integrado con las versiones más nuevas de xCode que OCUnit ....

La depuración de pruebas unitarias no requiere nada, funciona muy bien desde el principio. (Con xCode se necesita un montón de ajustes: http://chanson.livejournal.com/119578.html

Con GTB puede ejecutar las pruebas en el dispositivo y tiene herramientas para las pruebas de interfaz de usuario (parece que se puede crear una jerarquía UIView falso y luego compararlo con lo que tiene en tiempo de ejecución). soy escéptico acerca de la interfaz de usuario de pruebas automáticas (caro y difícil de mantener), pero eso es una buena característica!

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

Answer 2

Por cierto, el caso de prueba Google Herramientas ahora imprime comenzó mensajes en caso de que alguien se preguntaba ;-)