Où mettez-vous votre unité de test?

Question

J'ai trouvé plusieurs conventions pour les tests unitaires d'entretien dans un projet et Je ne suis pas sûr quelle approche serait appropriée pour notre prochain projet PHP. Je suis en essayant de trouver la meilleure convention pour encourager le développement facile et accessibilité des tests lors de l'examen du code source. Je serais très intéressé par votre expérience/opinion sur chacun:

1. Un dossier pour le code productif, un autre pour les tests unitaires: Cela sépare tests unitaires à partir des fichiers logiques du projet. Cette séparation de préoccupations est autant une nuisance que c'est un avantage: Quelqu'un regardant dans le code source du projet - donc je suppose - soit parcourir l'implémentation ou les tests unitaires (ou plus communément: la mise en œuvre seulement). L'avantage des tests unitaires étant un autre point de vue sur vos classes est perdu - ces deux points de vue sont trop éloignés IMO.
2. méthodes d'essai annotées: Tout cadre de tests unitaires modernes Je sais que permet aux développeurs de créer des méthodes de test dédiés, les annotant (@test) et les noyant dans le code du projet. Le gros inconvénient que je vois ici est que les fichiers du projet sont encombrés. Même si ces méthodes sont séparées en utilisant un en-tête de commentaire (comme UNIT TESTS en dessous de cette ligne) il bloque juste la classe inutilement.
3. fichiers de test dans les mêmes dossiers que les fichiers de mise en œuvre: Notre dossier convention de nommage dicte que les fichiers PHP contenant des classes (une classe par fichier) doivent se terminer par .class.php. Je pourrais imaginer que mettre l'unité tests concernant un fichier de classe dans un autre se terminant par .test.php rendre les tests beaucoup plus présents à d'autres développeurs sans ternir la classe. Bien qu'il gonfle les dossiers du projet, au lieu des fichiers d'implémentation , c'est mon favori jusqu'à présent, mais j'ai des doutes: je penserait que d'autres ont déjà trouvé cela, et mis au rebut cette option pour une raison quelconque (ie je n'ont pas vu un projet java avec les fichiers Foo.java et FooTest.java dans le même dossier.) Peut-être parce les développeurs java utilisent plus lourd des IDEs qui leur permettent un accès plus facile à les essais, alors que dans PHP pas de grands éditeurs ont émergé (comme Eclipse pour java) - de nombreux développeurs que je connais utilisent vim/emacs ou des éditeurs similaires avec un peu de support pour le développement PHP en soi .

Quelle est votre expérience avec l'un de ces stages de test unitaires? Avez-vous une autre convention que je n'ai pas listée ici? Ou est-ce que je ne fais que surévaluer l'unité de test l'accessibilité aux réviseurs?

Answer 1

Je vais toujours pour # 1. Bien que ce soit sympa, ils sont proches les uns des autres. Mes raisons sont les suivantes:

• Je pense qu'il existe une différence entre la base de code principale et les tests unitaires. J'ai besoin d'une vraie séparation.
• Les utilisateurs finaux ont rarement besoin de regarder unittests.Ils sont simplement intéressés par l'API. Bien qu'il soit agréable que les tests unitaires fournissent une vue séparée sur le code, en pratique, je pense qu'il ne sera pas utilisé pour mieux le comprendre. (plus de documentation descriptive + exemples font). Comme les utilisateurs finaux ont rarement besoin de tests unitaires, je ne veux pas les confondre avec plus de fichiers et/ou de méthodes.
• Mes normes de codage ne sont pas aussi strictes pour les tests unitaires que pour la bibliothèque principale. C'est peut-être juste mon opinion, mais je ne me soucie pas autant des normes de codage dans mes tests.

Espérons que cela aide.

Answer 2

Je préfère conserver les tests unitaires dans des fichiers source distincts dans le même répertoire que le code de production (# 3).

Les tests unitaires ne sont pas des citoyens de seconde classe, leur code doit être maintenu et refaçonné comme le code de production. Si vous conservez vos tests unitaires dans un répertoire distinct, le prochain développeur qui modifiera votre code de production risque de manquer des tests unitaires et de ne pas maintenir les tests.

En C++, je tendance à avoir trois fichiers par classe:

MyClass.h 
MyClass.cpp 
t_MyClass.cpp 

Si vous utilisez Vim, puis mon plug-in toggle_unit_tests pour basculer entre les fichiers de test source et l'unité peut se révéler utile.

Answer 3

La meilleure pratique actuelle consiste à séparer les tests unitaires dans leur propre répertoire, n ° 1. Tous les systèmes "convention over configuration" le font comme ça, par exemple. Maven, Rails, etc.

Je pense que vos alternatives sont intéressantes et valides, et le support d'outil est certainement là pour les supporter. Mais ce n'est pas si populaire (pour autant que je sache). Certaines personnes s'opposent à ce que les tests soient entrecoupés de code de production. Mais il est logique pour moi que si vous écrivez toujours des tests unitaires, qu'ils soient situés juste avec votre code. Cela semble simplement plus simple.