Les Tests unitaires des méthodes privées dans Xcode

Question

Je vais essayer de développement piloté par les tests dans un jouet projet. Je peux obtenir les tests de travail pour l'interface publique de mes classes (même si je suis encore sur la clôture, parce que je suis en train d'écrire plus de tests de code qu'il y a dans les méthodes d'essai).

J'ai tendance à utiliser beaucoup de méthodes privées parce que je tiens à garder le public des interfaces propres; cependant, je voudrais encore utiliser des tests sur ces méthodes.

Depuis de Cacao est un langage dynamique, je peux toujours appeler ces méthodes, mais je reçois des mises en garde dans mes tests que ma classe ne peut pas répondre à ces méthodes (même si elle n'a évidemment). Comme j'aime à le compiler avec pas de mise en garde voici mes questions:

1. Comment puis-je désactiver ces mises en garde dans Xcode?
2. Est-il autre chose que je pouvais faire pour désactiver ces mises en garde?
3. Suis-je en train de faire quelque chose de mal en essayant "boîte blanche" testing?

Answer 1

Rappelez-vous qu'il n'y a vraiment aucune une telle chose comme "les méthodes privées" en Objective-C, et il n'est pas juste parce que c'est un langage dynamique. De par sa conception, Objective-C a modificateurs de visibilité pour ivars, mais pas pour les méthodes - ce n'est pas par accident que vous pouvez appeler n'importe quelle méthode que vous aimez.

@Peterla suggestion est un grand. Pour compléter sa réponse, une alternative que j'ai utilisé (je n'ai pas envie/besoin d'un en-tête juste pour les méthodes privées) est à déclarer dans la catégorie de l'unité de test de fichier lui-même. (J'utilise @interface MyClass (Test) que le nom.) C'est une excellente façon d'ajouter des méthodes qui seraient inutiles ballonnement dans le code de la version, comme pour l'accès à ivars que la classe sous test a accès. (C'est évidemment moins un problème lorsque les propriétés sont utilisées.)

J'ai trouvé cette approche facilite l'exposition et de vérifier l'état interne, ainsi que l'ajout de test uniquement des méthodes. Par exemple, dans cette unité fichier de test, j'ai écrit un -isValid méthode de vérification de l'exactitude des tas binaire. Dans la production, cette méthode serait un gaspillage de l'espace, car je suppose qu'un tas de validité - je ne garde à ce sujet lors des essais de test de l'unité des régressions si je modifie le code.

Answer 2

Comment puis-je désactiver ces mises en garde dans Xcode?

Ne le faites pas.

Est-il autre chose que je pouvais faire pour désactiver ces mises en garde?

Ne le faites pas.

Suis-je en train de faire quelque chose de mal en essayant "boîte blanche" testing?

Pas de.

La solution est de déplacer vos méthodes privées à une catégorie dans son propre en-tête. Importation de cet en-tête dans le réel de la classe et de test-catégorie fichiers de mise en œuvre.

Answer 3

Ressemble à une autre question a la réponse: http://stackoverflow.com/questions/194666/is-there-a-way-to-suppress-warnings-in-xcode

Answer 4

Tout en avoir un en-tête ou définir votre propre catégorie sont probablement plus correct de solutions il y a aussi une autre solution très simple: convertir l'objet d'identification (id) avant d'appeler la méthode.

Answer 5

J'avais le même problème quand j'ai commencé avec TDD il ya quelques jours. J'ai trouvé cela très intéressant le point de vue du Test-Driven Développement iOS du livre:

Je me suis souvent demandé, "Devrais-je tester mes méthodes privées?" ou liés à la question "Comment dois-je tester mes méthodes privées?" Les personnes demandant à la deuxième question, ont supposé que la réponse à la première est "Oui" et sont maintenant à la recherche d'un moyen d'exposer leurs classes privée des interfaces dans leurs suites de test.

Ma réponse s'appuie sur l'observation d'un subtil fait: Vous avez déjà testé vos méthodes privées. En suivant le rouge–vert–refactoriser approche commune dans le développement piloté par les tests, vous avez conçu vos objets Api publiques pour faire le travail de ces objets ont besoin de le faire. Avec ce travail spécifié par les tests et la continuité de l'exécution des tests en vous assurant que vous n'avez rien de cassé-vous êtes libre d'organiser l'intérieur de la plomberie de votre classe que vous voyez l'ajustement.

Vos méthodes privées sont déjà testé parce que tout ce que vous faites est de refactoring comportement que vous avez déjà des tests pour. Vous ne devriez jamais vous retrouver dans une situation où une méthode privée n'a pas été testé ou incomplètement testé, parce que vous créez lorsque vous en voyez-vous une possibilité de nettoyer la mise en œuvre des méthodes publiques. Cela garantit que les méthodes privées n'existent qu'à l'appui de la classe qu'ils doivent être invoquée pendant les tests, car ils sont certainement appelées à partir de méthodes publiques.