2009-12-14 5 views
10

J'essaie de choisir entre OCUnit et Google Tool Box, avez-vous des préférences, recommanderiez-vous l'un ou l'autre, pourquoi? Je serais très intéressé d'entendre parler de vos expériences avec l'un des 2.Tests unitaires et TDD, OCUnit vs Google Tool Box

Le principal problème que j'ai avec deux d'entre eux est le managment des accidents dans les méthodes testées (ex: ACCESS BAD) Aucun d'entre eux a pu pour me dire dans quelle classe l'accident s'est produit !!!

Avec Google Boîte à outils je peux voir que la suite de tests était dirigé mais pas le cas de test (comment êtes-vous censé faire quand votre suite de test a 50 cas de test?)

Avec OCUnit je peux au moins voir quel cas de test dans quelle suite de tests a provoqué le crash?

Voici le genre de message que j'ai avec 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 

Je peux voir que c'est elle la suite de tests « LogicTests » qui a pris naissance l'accident, mais c'est tout.

Avec OCUnit est ici le message pour la même erreur:

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

Au moins avec OCUnit i peut suivre ce cas test a été en cours d'exécution et éventuellement déboguer (mais qui pourrait prendre très longtemps sans informations sur la classe et le numéro de ligne ...)

Comment gérez-vous ces problèmes?

Merci d'avance.

PS: voici comment reproduire le problème, il est très simple:

Il suffit de créer une classe avec une méthode qui se bloque quand il est appelé (ce qui arrive tout le temps quand vous faites TDD):

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

Et puis créez un test qui appelle ces méthodes:

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

Merci à l'avance, Vincent

Répondre

3

Je pense que je vais quand même .. avec GTB

avec Xcode 3.2 erreurs de OCUnit et les avertissements ne sont pas apparaître à l'intérieur du code. Semble que c'est un problème connu: lhttp://osdir.com/ml/xcode-users/2009-10/msg00216.html

Avec GTB cela fonctionne très bien. Je ne peux pas le croire mais il semble que GTB est mieux intégré avec les nouvelles versions de xCode que OCUnit ....

Le débogage des tests unitaires ne nécessite rien, il fonctionne très bien dès le départ. (Avec Xcode vous avez besoin d'un tas de paramètres: http://chanson.livejournal.com/119578.html

Avec GTB vous pouvez exécuter vos tests sur l'appareil et vous avez des outils pour les tests de l'interface utilisateur (vous semble pouvez créer une hiérarchie de UIView faux et puis le comparer avec ce que vous avez à l'exécution) Je suis sceptique quant aux tests automatiques de l'interface utilisateur (coûteux et difficile à maintenir) mais c'est une fonctionnalité intéressante!

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

+0

@ user142764: comment voulez-vous les tests unitaires de débogage avec GTB alors? Vous avez sûrement besoin d'un exécutable personnalisé? – jkp

+0

Non, c'est génial avec GTB: puisque vous utilisez une cible normale pour lancer vos tests, vous pouvez le déboguer! Il suffit d'écrire un test, de placer un point d'arrêt à l'intérieur, puis de lancer Run-> Debug depuis le menu et voilà: vous déboguez votre test pas à pas. – user142764

0

BTW la boîte à outils Google affiche désormais des messages cas de test a commencé au cas où quelqu'un se demandait ;-)