Qu'est-ce qui fait un bon test unitaire? [fermé]

Je suis sûr que la plupart d'entre vous écrivez beaucoup de tests automatisés et que vous avez également rencontré des pièges courants lors des tests unitaires.

Ma question est de savoir si vous suivez des règles de conduite pour rédiger des tests afin d'éviter des problèmes à l'avenir? Pour être plus précis: quelles sont les propriétés des bons tests unitaires ou comment rédigez-vous vos tests?

Les suggestions indépendantes de la langue sont encouragées.

Permettez-moi de commencer par brancher les sources - Test d'unité pragmatique en Java avec JUnit (Il existe une version avec C # -Nunit aussi .. mais j'ai celui-ci .. son agnostique pour la plupart. Recommandé.)

Les bons tests devraient être UN VOYAGE (l'acronyme n'est pas assez collant - j'ai une impression de la feuille de triche dans le livre que j'ai dû retirer pour m'assurer d'avoir bien compris ..)

• Automatique : l'appel des tests ainsi que la vérification des résultats pour PASS / FAIL doivent être automatiques
• Complet : couverture; Bien que les bogues aient tendance à se regrouper autour de certaines régions du code, assurez-vous de tester tous les chemins et scénarios clés. Utilisez des outils si vous devez connaître les régions non testées
• Répétable : les tests doivent produire les mêmes résultats à chaque fois ... à chaque fois. Les tests ne doivent pas reposer sur des paramètres incontrôlables.
• Indépendant : très important.
  • Les tests ne doivent tester qu'une seule chose à la fois. Les assertions multiples sont acceptables tant qu'elles testent toutes une fonctionnalité / un comportement. Lorsqu'un test échoue, il doit identifier l'emplacement du problème.
  • Les tests ne doivent pas s'appuyer les uns sur les autres - Isolés. Aucune hypothèse sur l'ordre d'exécution des tests. Assurez-vous de `` nettoyer la table '' avant chaque test en utilisant correctement la configuration / le démontage

• Professionnel : à long terme, vous aurez autant de code de test que de production (sinon plus), donc suivez le même standard de bonne conception pour votre code de test. Méthodes-classes bien factorisées avec des noms révélateurs d'intention, pas de duplication, des tests avec de bons noms, etc.

• Les bons tests fonctionnent également rapidement . tout test qui prend plus d'une demi-seconde à exécuter .. doit être travaillé. Plus la suite de tests prend du temps pour une exécution ... moins elle sera exécutée fréquemment. Plus le développeur essaiera de faire de changements entre les exécutions ... si quelque chose casse ... il faudra plus de temps pour déterminer quel changement est à l'origine.

Mise à jour 2010-08:

• Lisible : cela peut être considéré comme faisant partie de Professional - mais on ne saurait trop le souligner. Un test d'acide serait de trouver quelqu'un qui ne fait pas partie de votre équipe et de lui demander de comprendre le comportement testé en quelques minutes. Les tests doivent être maintenus tout comme le code de production - rendez-le donc facile à lire même si cela demande plus d'efforts. Les tests doivent être symétriques (suivre un modèle) et concis (tester un comportement à la fois). Utilisez une convention de dénomination cohérente (par exemple, le style TestDox). Évitez d'encombrer le test avec des «détails accessoires» .. devenez minimaliste.

En dehors de ceux-ci, la plupart des autres sont des directives qui réduisent le travail à faible bénéfice: par exemple, «Ne testez pas le code que vous ne possédez pas» (par exemple les DLL tierces). Ne testez pas les getters et les setters. Gardez un œil sur le rapport coût-bénéfice ou la probabilité de défaut.

1. N'écrivez pas de tests énormes. Comme le suggère «l'unité» du «test unitaire», faites en sorte que chacun d'eux soit aussi atomique et isolé que possible. Si vous le devez, créez des conditions préalables à l'aide d'objets fictifs, plutôt que de recréer manuellement une trop grande partie de l'environnement utilisateur typique.
2. Ne testez pas des choses qui fonctionnent évidemment. Évitez de tester les classes d'un fournisseur tiers, en particulier celui qui fournit les API de base du framework dans lequel vous codez. Par exemple, ne testez pas l'ajout d'un élément à la classe Hashtable du fournisseur.
3. Pensez à utiliser un outil de couverture de code tel que NCover pour vous aider à découvrir les cas limites que vous n'avez pas encore testés.
4. Essayez d'écrire le test avant l'implémentation. Considérez le test comme une spécification à laquelle votre implémentation adhèrera. Cf. également le développement axé sur le comportement, une branche plus spécifique du développement axé sur les tests.
5. Être cohérent. Si vous n'écrivez des tests que pour une partie de votre code, ce n'est guère utile. Si vous travaillez en équipe et que certains ou tous les autres n'écrivent pas de tests, ce n'est pas très utile non plus. Convainquez-vous et tout le monde de l'importance (et des propriétés de gain de temps ) des tests, ou ne vous inquiétez pas.

La plupart des réponses ici semblent aborder les meilleures pratiques des tests unitaires en général (quand, où, pourquoi et quoi), plutôt que d'écrire les tests eux-mêmes (comment). Comme la question me paraissait assez précise sur la partie «comment», j'ai pensé poster ceci, tiré d'une présentation «sac marron» que j'avais menée dans mon entreprise.

Les 5 lois de rédaction des tests de Womp:

1. Utilisez des noms de méthode de test longs et descriptifs.

   - Map_DefaultConstructorShouldCreateEmptyGisMap()
   - ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
   - Dog_Object_Should_Eat_Homework_Object_When_Hungry()

2. Écrivez vos tests dans un style Arrange / Act / Assert .

• Bien que cette stratégie organisationnelle existe depuis un certain temps et s'appelle beaucoup de choses, l'introduction récente de l'acronyme «AAA» a été un excellent moyen de faire passer cela. Rendre tous vos tests cohérents avec le style AAA les rend faciles à lire et à maintenir.

3. Fournissez toujours un message d'échec avec vos assertions.

Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element 
processing events was raised by the XElementSerializer");

• Une pratique simple mais enrichissante qui montre clairement dans votre application de coureur ce qui a échoué. Si vous ne fournissez pas de message, vous obtiendrez généralement quelque chose comme "Attendu vrai, était faux" dans votre sortie d'échec, ce qui vous obligera à lire le test pour découvrir ce qui ne va pas.

4. Commentez la raison du test - quelle est l'hypothèse commerciale?

  /// A layer cannot be constructed with a null gisLayer, as every function 
  /// in the Layer class assumes that a valid gisLayer is present.
  [Test]
  public void ShouldNotAllowConstructionWithANullGisLayer()
  {
  }

• Cela peut sembler évident, mais cette pratique protégera l'intégrité de vos tests des personnes qui ne comprennent pas la raison du test en premier lieu. J'ai vu de nombreux tests supprimés ou modifiés qui allaient parfaitement bien, simplement parce que la personne ne comprenait pas les hypothèses que le test vérifiait.
• Si le test est trivial ou si le nom de la méthode est suffisamment descriptif, il peut être permis de laisser le commentaire désactivé.

5. Chaque test doit toujours rétablir l'état de toute ressource qu'il touche

• Utilisez des simulacres lorsque cela est possible pour éviter de vous occuper de ressources réelles.
• Le nettoyage doit être effectué au niveau du test. Les tests ne doivent pas dépendre de l'ordre d'exécution.

Gardez ces objectifs à l'esprit (adapté du livre xUnit Test Patterns de Meszaros)

• Les tests doivent réduire le risque et non l'introduire.
• Les tests doivent être faciles à exécuter.
• Les tests doivent être faciles à maintenir à mesure que le système évolue autour d'eux

Quelques choses pour vous faciliter la tâche:

• Les tests ne doivent échouer que pour une raison.
• Les tests ne doivent tester qu'une seule chose
• Minimisez les dépendances de test (pas de dépendances sur les bases de données, les fichiers, l'interface utilisateur, etc.)

N'oubliez pas que vous pouvez également faire des tests d'intégration avec votre framework xUnit, mais gardez les tests d'intégration et les tests unitaires séparés

Les tests doivent être isolés. Un test ne doit pas dépendre d'un autre. De plus, un test ne doit pas s'appuyer sur des systèmes externes. En d'autres termes, testez votre code, pas le code dont dépend votre code. Vous pouvez tester ces interactions dans le cadre de votre intégration ou de vos tests fonctionnels.

Quelques propriétés de bons tests unitaires:

• Lorsqu'un test échoue, il devrait être immédiatement évident où se situe le problème. Si vous devez utiliser le débogueur pour localiser le problème, vos tests ne sont pas assez granulaires. Avoir exactement une assertion par test aide ici.

• Lorsque vous refactorisez, aucun test ne doit échouer.

• Les tests doivent être exécutés si vite que vous n’hésitez jamais à les exécuter.

• Tous les tests doivent toujours réussir; pas de résultats non déterministes.

• Les tests unitaires doivent être bien pris en compte, tout comme votre code de production.

@Alotor: Si vous suggérez qu'une bibliothèque ne devrait avoir que des tests unitaires sur son API externe, je ne suis pas d'accord. Je veux des tests unitaires pour chaque classe, y compris des classes que je n'expose pas aux appelants externes. (Cependant, si je ressens le besoin d'écrire des tests pour des méthodes privées, alors je dois refactoriser. )

EDIT: Il y avait un commentaire sur la duplication causée par "une assertion par test". Plus précisément, si vous avez du code pour configurer un scénario et que vous souhaitez ensuite faire plusieurs affirmations à ce sujet, mais que vous n'avez qu'une seule assertion par test, vous pouvez dupliquer la configuration sur plusieurs tests.

Je n'adopte pas cette approche. Au lieu de cela, j'utilise des montages de test par scénario . Voici un exemple approximatif:

[TestFixture]
public class StackTests
{
    [TestFixture]
    public class EmptyTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
        }

        [TestMethod]
        [ExpectedException (typeof(Exception))]
        public void PopFails()
        {
            _stack.Pop();
        }

        [TestMethod]
        public void IsEmpty()
        {
            Assert(_stack.IsEmpty());
        }
    }

    [TestFixture]
    public class PushedOneTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
            _stack.Push(7);
        }

        // Tests for one item on the stack...
    }
}

Ce que vous recherchez, c'est la délimitation des comportements de la classe testée.

1. Vérification des comportements attendus.
2. Vérification des cas d'erreur.
3. Couverture de tous les chemins de code dans la classe.
4. Exercer toutes les fonctions des membres au sein de la classe.

L'intention de base est d'augmenter votre confiance dans le comportement de la classe.

Ceci est particulièrement utile lorsque vous envisagez de refactoriser votre code. Martin Fowler a un intéressant article concernant les tests sur son site Web.

HTH.

à votre santé,

Rob

Le test devrait initialement échouer. Ensuite, vous devez écrire le code qui les fait passer, sinon vous courez le risque d'écrire un test qui est bogué et qui réussit toujours.

J'aime l'acronyme Right BICEP du livre Pragmatic Unit Testing susmentionné :

• Droite : les résultats sont-ils corrects ?
• B : Est -ce toutes les b conditions oundary corriger?
• Je : Pouvons - nous vérifier i nverse relations?
• C : Peut - on c résultats ross-contrôle à l' aide d' autres moyens?
• E : Peut - on forcer e conditions rror arriver?
• P : Y a- p caractéristiques de limites dans PERFORMANCE?

Personnellement, je pense que vous pouvez aller assez loin en vérifiant que vous obtenez les bons résultats (1 + 1 devrait renvoyer 2 dans une fonction d'addition), en essayant toutes les conditions aux limites auxquelles vous pouvez penser (comme utiliser deux nombres dont la somme est supérieur à la valeur maximale de l'entier dans la fonction d'ajout) et forçant des conditions d'erreur telles que des pannes de réseau.

Les bons tests doivent être maintenables.

Je n'ai pas tout à fait compris comment faire cela pour des environnements complexes.

Tous les manuels commencent à se décoller alors que votre base de code commence à atteindre des centaines de milliers ou des millions de lignes de code.

• Les interactions d'équipe explosent
• nombre de cas de test explosent
• les interactions entre les composants explosent.
• le temps de construire tous les unittests devient une partie importante du temps de construction
• un changement d'API peut se répercuter sur des centaines de cas de test. Même si le changement de code de production a été facile.
• le nombre d'événements requis pour séquencer les processus dans le bon état augmente, ce qui augmente le temps d'exécution des tests.

Une bonne architecture peut contrôler une partie de l'explosion des interactions, mais inévitablement, à mesure que les systèmes deviennent plus complexes, le système de test automatisé évolue avec elle.

C'est là que vous commencez à devoir faire des compromis:

• tester uniquement l'API externe, sinon la refactorisation des composants internes entraîne une refonte significative du scénario de test.
• la configuration et le démontage de chaque test deviennent plus compliqués car un sous-système encapsulé conserve plus d'état.
• La compilation nocturne et l'exécution de tests automatisés prennent des heures.
• l'augmentation des temps de compilation et d'exécution signifie que les concepteurs n'exécutent pas ou n'exécuteront pas tous les tests
• pour réduire les temps d'exécution des tests que vous envisagez de séquencer les tests à prendre, réduire la configuration et le démontage

Vous devez également décider:

où stockez-vous les cas de test dans votre base de code?

• comment documentez-vous vos cas de test?
• les appareils de test peuvent-ils être réutilisés pour économiser la maintenance du cas de test?
• que se passe-t-il lorsqu'une exécution de cas de test nocturne échoue? Qui fait le triage?
• Comment entretenez-vous les objets simulés? Si vous avez 20 modules utilisant tous leur propre saveur d'une API de journalisation fictive, changer les ondulations de l'API rapidement. Non seulement les cas de test changent, mais les 20 objets simulés changent. Ces 20 modules ont été écrits sur plusieurs années par de nombreuses équipes différentes. C'est un problème de réutilisation classique.
• les individus et leurs équipes comprennent la valeur des tests automatisés, ils n'aiment tout simplement pas la façon dont l'autre équipe le fait. :-)

Je pourrais continuer indéfiniment, mais mon argument est que:

Les tests doivent être maintenables.

J'ai couvert ces principes il y a quelque temps dans cet article de MSDN Magazine que je pense qu'il est important pour tout développeur de le lire.

La façon dont je définis les "bons" tests unitaires est de savoir s'ils possèdent les trois propriétés suivantes:

• Ils sont lisibles (dénomination, assertions, variables, longueur, complexité ..)
• Ils sont maintenables (pas de logique, pas de spécification excessive, basée sur l'état, refactorisée ..)
• Ils sont dignes de confiance (testez la bonne chose, isolés, pas des tests d'intégration ..)

• Les tests unitaires ne font que tester l'API externe de votre unité, vous ne devriez pas tester le comportement interne.
• Chaque test d'un TestCase doit tester une (et une seule) méthode dans cette API.
  • Des cas de test supplémentaires doivent être inclus pour les cas d'échec.
• Testez la couverture de vos tests: une fois l'unité testée, 100% des lignes à l'intérieur de cette unité devraient avoir été exécutées.

Jay Fields a beaucoup de bons conseils sur l'écriture de tests unitaires et il y a un article où il résume les conseils les plus importants . Vous y lirez que vous devez réfléchir de manière critique à votre contexte et juger si les conseils vous valent. Vous obtenez une tonne de réponses étonnantes ici, mais c'est à vous de décider ce qui convient le mieux à votre contexte. Essayez-les et refactorisez-les si cela sent mauvais pour vous.

Sincères amitiés

Ne supposez jamais qu'une méthode triviale de 2 lignes fonctionnera. L'écriture d'un test unitaire rapide est le seul moyen d'éviter que le test nul manquant, le signe moins égaré et / ou une erreur de portée subtile ne vous mordent, inévitablement lorsque vous avez encore moins de temps que maintenant.

J'appuie la réponse "A TRIP", sauf que les tests DEVRAIENT s'appuyer les uns sur les autres !!!

Pourquoi?

DRY - Ne vous répétez pas - s'applique également aux tests! Les dépendances de test peuvent aider 1) à gagner du temps de configuration, 2) à économiser les ressources de l'appareil et 3) à identifier les échecs. Bien sûr, seulement étant donné que votre framework de test prend en charge les dépendances de première classe. Sinon, je l'avoue, ils sont mauvais.

Suivi http://www.iam.unibe.ch/~scg/Research/JExample/

Les tests unitaires sont souvent basés sur des objets ou des données factices. J'aime écrire trois types de tests unitaires:

• tests unitaires «transitoires»: ils créent leurs propres objets / données fictifs et testent leur fonction avec, mais détruisent tout et ne laissent aucune trace (comme aucune donnée dans une base de données de test)
• test unitaire "persistant": ils testent les fonctions au sein de votre code en créant des objets / données qui seront nécessaires ultérieurement à des fonctions plus avancées pour leur propre test unitaire (évitant à ces fonctions avancées de recréer à chaque fois leur propre ensemble d'objets / données fictifs)
• Tests unitaires "persistants": tests unitaires utilisant des objets / données fictifs qui sont déjà là (car créés dans une autre session de test unitaire) par les tests unitaires persistants.

Le but est d'éviter de tout rejouer pour pouvoir tester toutes les fonctions.

• Je lance le troisième type très souvent car tous les objets / données fictifs sont déjà là.
• Je lance le deuxième type chaque fois que mon modèle change.
• Je lance le premier pour vérifier les fonctions très basiques de temps en temps, pour vérifier les régressions de base.

Pensez aux 2 types de tests et traitez-les différemment: les tests fonctionnels et les tests de performance.

Utilisez des entrées et des métriques différentes pour chacun. Vous devrez peut-être utiliser un logiciel différent pour chaque type de test.

J'utilise une convention de dénomination de test cohérente décrite par les normes de dénomination de test unitaire de Roy Osherove Chaque méthode dans une classe de cas de test donnée a le style de dénomination MethodUnderTest_Scenario_ExpectedResult suivant.

La première section de nom de test est le nom de la méthode dans le système testé.

Vient ensuite le scénario spécifique qui est testé.

Enfin, les résultats de ce scénario.

Chaque section utilise Upper Camel Case et est délimitée par un sous-score.

J'ai trouvé cela utile lorsque j'exécute le test, les tests sont regroupés par le nom de la méthode testée. Et avoir une convention permet aux autres développeurs de comprendre l'intention du test.

J'ajoute également des paramètres au nom de la méthode si la méthode testée a été surchargée.