Directives de test unitaire

Question

Quelqu'un sait-il où trouver les directives et recommandations relatives aux tests unitaires? J'aimerais avoir quelque chose qui aborde les types de sujets suivants (par exemple):

• Les tests doivent-ils être dans le même projet que la logique d'application?
• Devrais-je avoir des classes de test pour refléter mes classes de logique ou devrais-je avoir seulement autant de classes de test que nécessaire?
• Comment dois-je nommer mes classes de test, méthodes et projets (s'ils vont dans différents projets)
• Les méthodes privées, protégées et internes doivent-elles être testées ou uniquement celles qui sont accessibles au public?
• Les tests unitaires et d'intégration doivent-ils être séparés?
• Existe-t-il une bonne raison de ne pas bénéficier d'une couverture de test à 100%?

Qu'est-ce que je ne demande pas à propos de ce que je devrais être?

Une ressource en ligne serait préférable.

Answer 1

Je recommanderais le livre de Kent Beck sur TDD.

Vous devez également vous rendre sur le site de Martin Fowler . Il dispose également de nombreuses informations utiles sur les tests.

Nous sommes assez gros sur le TDD, je vais donc répondre aux questions de cette manière.

  

Les tests doivent-ils être dans le même projet que la logique d'application?

En règle générale, nous conservons nos tests dans la même solution, mais nous divisons les tests en DLL / projets distincts qui reflètent les DLL / projets qu'ils testent, mais nous conservons des espaces de noms avec les tests situés dans un sous-espace de noms. Exemple: Common / Common.Tests

  

Devrais-je avoir des classes de test pour refléter mes classes de logique ou devrais-je avoir seulement autant de classes de test que nécessaire?

Oui, vos tests doivent être créés avant la création des classes. Par définition, vous ne devez tester qu’une seule unité de manière isolée. Par conséquent, vous devriez avoir une classe de test pour chaque classe de votre solution.

  

Comment nommer mes classes, méthodes et projets de test (s’ils vont dans différents projets)

Je tiens à souligner que le comportement est ce qui est testé, donc je nomme généralement les classes de test après le SUT. Par exemple, si j’avais une classe d’utilisateur, je nommerais la classe de test comme suit:

public class UserBehavior

Les méthodes doivent être nommées pour décrire le comportement attendu.

public void ShouldBeAbleToSetUserFirstName()

Les projets peuvent être nommés comme vous le souhaitez, mais vous souhaitez généralement que le projet qu’il teste soit assez évident. Voir la réponse précédente à propos de l'organisation du projet.

  

Les méthodes privées, protégées et internes doivent-elles être testées ou uniquement celles qui sont accessibles au public?

Encore une fois, vous souhaitez que les tests vérifient le comportement attendu comme si vous étiez un consommateur tiers des objets testés. Si vous testez les détails de la mise en œuvre interne, vos tests seront fragiles. Vous voulez que votre test vous donne la liberté de refactoriser sans vous soucier de casser les fonctionnalités existantes. Si votre test connaît les détails de la mise en oeuvre, vous devrez les modifier si ces détails changent.

  

Les tests unitaires et d'intégration doivent-ils être séparés?

Oui, les tests unitaires doivent être isolés des tests d'acceptation et d'intégration. La séparation des préoccupations s’applique également aux tests.

  

Existe-t-il une bonne raison de ne pas bénéficier d’une couverture de test à 100%?

Je n'arriverais pas à raccrocher à la couverture de code à 100%. Une couverture de code à 100% implique généralement un niveau de qualité des tests, mais c'est un mythe. Vous pouvez avoir des tests terribles et toujours obtenir une couverture de 100%. Je voudrais plutôt compter sur une bonne mentalité Test First. Si vous écrivez toujours un test avant d’écrire une ligne de code, vous vous assurez d’une couverture à 100% pour que cela devienne un point discutable.

En général, si vous vous concentrez sur une description complète de la portée comportementale de la classe, vous n’aurez plus rien à craindre. Si vous faites de la couverture de code une métrique, les programmeurs fainéants en feront tout simplement assez pour répondre à cette cible et vous aurez toujours des tests de mauvaise qualité. Fiez-vous plutôt aux examens par les pairs, où les tests sont également passés en revue.

Answer 2

C'est une bonne question. Nous avons grandi organiquement, et je suppose que le meilleur moyen est bien cela. Il y a un peu "Cela dépend ..." à l'intérieur.

Nous effectuons des tests dans le même projet, dans un sous-espace de noms appelé "UnitTes"

.

Nos classes de test reflètent la classe logique, afin de simplifier le suivi de l'emplacement des tests par rapport à ce qu'ils testent

Les classes sont nommées comme la classe logique qu'elles testent, les méthodes sont nommées pour le scénario qu'elles testent.

Nous n'écrivons que des tests pour le public et des méthodes internes (les tests appartiennent au même projet), et nous visons une couverture de 95% de la classe.

Je préfère ne pas distinguer entre "unité". et "l'intergénation". Vous passerez trop de temps à essayer de savoir lequel est ce sac. Un test est un test.

100% est trop difficile à atteindre tout le temps. Nous visons 95%. Il y a aussi un rendement décroissant sur le temps qu'il faudra pour atteindre ces 5% finaux et ce qu'il va réellement attraper.

C’est nous et ce qui convient à l’environnement et au rythme. Votre kilométrage peut varier. Pensez à votre environnement et aux personnalités impliquées.

J'ai hâte de voir ce que les autres ont à dire sur celui-ci!

Answer 3

La réponse de Josh est exacte: juste un éclaircissement:

La rapidité est la raison pour laquelle je distingue les tests unitaires des tests d'intégration et des tests d'acceptation. J'utilise TDD. J'ai besoin d'un retour d'information instantané sur la ligne de code que je viens de créer / modifier. Je ne peux pas obtenir cela si j'exécute des suites complètes de tests d'intégration et / ou d'acceptation, des tests qui touchent de vrais disques, des réseaux réels et des systèmes externes vraiment lents et imprévisibles.

Ne croisez pas les poutres. De mauvaises choses vont arriver si vous faites.

Answer 4

Je vous recommande vivement de lire le développement piloté par les tests: exemple et Le développement piloté par les tests: un guide pratique C'est trop de questions pour un seul sujet

Answer 5

En ce qui concerne votre dernière question, selon mon expérience, le "bon" La raison pour laquelle nous n’insistons pas pour une couverture de test à 100% est qu’il faut déployer des efforts disproportionnés pour obtenir les derniers points de pourcentage, en particulier dans les bases de code plus grandes. En tant que tel, il s’agit de décider si vous valez ou non votre temps une fois que vous atteignez ce point de rendement décroissant.

Answer 6

Dans l'ordre:

• Non, il est généralement préférable de les inclure dans un projet séparé. sauf si vous voulez pouvoir exécuter des diagnostics au moment de l'exécution.
• L'idéal est une couverture de code à 100%, ce qui signifie chaque ligne de code dans chaque routine de chaque classe.
• Je vais avec ClassnameTest, ClassnameTest.MethodNameTestnumber
• Tout.
• Je dirais que oui, car les tests d'intégration n'ont pas besoin d'être exécutés si les tests unitaires échouent.
• Les propriétés simples qui définissent et obtiennent un champ n'ont pas besoin d'être testées.

Answer 7

Les tests doivent-ils appartenir au même projet que la logique d'application?

Cela dépend. Il y a des compromis dans les deux sens.

Le conserver dans un projet nécessite une bande passante supplémentaire pour distribuer votre projet, un temps de construction supplémentaire, une empreinte au sol accrue et une erreur de mise en oeuvre de la logique de production dépendant du code de test.

D'autre part, garder des projets séparés peut rendre plus difficile la rédaction de tests impliquant des méthodes / classes privées (selon le langage de programmation), et entraîner des problèmes d'administration minimes, tels que la configuration d'un nouvel environnement de développement (par exemple, une nouvelle développeur rejoint le projet) plus difficile.

L'importance de ces coûts varie selon les projets. Il n'y a donc pas de réponse universelle.

Devrais-je avoir des classes de test pour refléter mes classes de logique ou devrais-je n'avoir que le nombre de classes de test dont j'ai besoin?

Non.

Vous devez avoir des classes de test permettant un code de test bien pondéré (duplication minimale, intention claire, etc.).

L’avantage évident de refléter directement les classes logiques dans vos classes de test est qu’il est facile de trouver les tests correspondant à un élément de code particulier. Il existe d'autres moyens de résoudre ce problème sans restreindre la flexibilité du code de test. De simples conventions de nommage pour les modules et les classes de test suffisent généralement.

Comment nommer mes classes, méthodes et projets de test (s'ils vont dans différents projets)

Vous devez les nommer pour que:

• chaque classe et méthode de test a un but clair, et
• pour qu'une personne à la recherche d'un test particulier (ou de tests relatifs à une unité particulière) puisse le trouver facilement.

Les méthodes privées, protégées et internes doivent-elles être testées ou uniquement celles qui sont accessibles au public?

Souvent, les méthodes non publiques doivent être testées. Cela dépend si vous obtenez suffisamment de confiance en testant simplement l'interface publique ou si l'unité que vous souhaitez réellement tester n'est pas accessible publiquement.

Les tests unitaires et d'intégration doivent-ils être séparés?

Cela dépend de votre choix de cadre (s) de test. Faites ce qui vous convient le mieux avec votre (vos) framework (s) de test et faites en sorte que:

• les tests unitaires et les tests d'intégration relatifs à un morceau de code sont faciles à trouver,
• il est facile d'exécuter uniquement les tests unitaires,
• il est facile d'exécuter uniquement les tests d'intégration,
• il est facile d'exécuter tous les tests.

Existe-t-il une bonne raison de ne pas bénéficier d'une couverture de test à 100%?

Oui, il y a une bonne raison. Strictement parlant, «couverture de test à 100%» signifie que toutes les situations possibles dans votre code sont exercées et testées. Cela n’est tout simplement pas pratique pour la plupart des projets.

Si vous entendez simplement par «couverture de 100% des tests», cela signifie que chaque ligne de code source est exercée par la suite de tests à un moment donné, alors il s'agit d'un bon objectif, mais il y a parfois quelques lignes dans des endroits difficiles d'accès. difficiles à atteindre avec des tests automatisés. Si le coût de la vérification manuelle de cette fonctionnalité périodiquement est inférieur au coût de contorsions pour atteindre ces cinq dernières lignes, c'est une bonne raison de ne pas bénéficier d'une couverture à 100%.

Plutôt qu'une simple règle selon laquelle vous devriez couvrir 100% des lignes, encouragez vos développeurs à découvrir les lacunes dans vos tests et à trouver des moyens de les combler, que le nombre de lignes soit suffisant ou non " couvert »améliore. En d’autres termes, si vous mesurez les lignes couvertes, vous améliorerez votre couverture de ligne - mais ce que vous voulez réellement, c’est une qualité améliorée. N'oubliez donc pas que la couverture en lignes est une approximation très grossière de la qualité.