195 votes

Ce sont des conventions de nommage pour les Tests Unitaires?

Général

  • Suivez les mêmes normes pour tous les tests.
  • Être clair sur ce que chaque test de l'état.
  • Être précis sur le comportement attendu.

Exemples

1) MethodName_StateUnderTest_Expectedbehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

source: http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html

2) En Séparant Chaque Mot Par Un Trait De Soulignement

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

D'autres

  • Fin des noms de méthode avec Test
  • Méthode de démarrage des noms avec le nom de classe

88voto

Rob Cooper Points 15945

Je suis à peu près avec vous sur cet homme. Les conventions de nommage que vous avez utilisé sont:

  • Clair sur ce que chaque test de l'état.
  • Spécifiques sur le comportement attendu.

Quoi de plus avez-vous besoin d'un nom de test?

Contrairement à Ray réponse je ne pense pas que le Test préfixe est nécessaire. C'est le code de test, nous le savons. Si vous avez besoin de le faire pour identifier le code, alors vous avez plus de problèmes, votre code de test ne doit pas être mélangé avec votre code de production.

Comme pour la longueur et l'utilisation de l'underscore, son code de test, l'enfer qui s'en soucie? Seuls vous et votre équipe va le voir, tant que c'est lisible et clair sur ce que le test est fait, continuez! :)

Cela dit, je suis encore assez nouveau pour les essais et les blogs de mes aventures avec elle :)

35voto

Lucifer Points 3431

C'est aussi intéressant à lire: la Structuration des Tests Unitaires

La structure a une classe de test par classe en cours d'essai. Ce n'est pas si inhabituel. Mais ce qui était inhabituel pour moi, c'était qu'il avait une classe imbriquée pour chaque méthode testée.

par exemple

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

Et voici pourquoi:

Eh bien pour une chose, c'est une belle façon de garder des tests organisés. Tous les les tests (ou faits) d'une méthode sont regroupés. Par exemple, si vous utilisez la combinaison de touches CTRL+M CTRL+O raccourci à l'effondrement corps de méthode, vous pouvez analysez facilement vos tests et de les lire comme une spécification pour votre code.

J'aime aussi cette approche:

MethodName_StateUnderTest_Expectedbehavior

Alors peut-être ajuster à:

StateUnderTest_ExpectedBehavior

Parce que chaque test sera déjà dans une classe imbriquée

25voto

CodingWithSpike Points 17720

J'ai tendance à utiliser la convention d' MethodName_DoesWhat_WhenTheseConditions ainsi, par exemple:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Cependant, ce que je ne vois que beaucoup est de rendre le nom de test de suivre les tests unitaires de la structure de

  • Organiser
  • Loi
  • Affirmer

Qui suit également la BDD / Cornichon syntaxe:

  • Compte tenu de
  • Lorsque
  • Alors

ce qui aura pour nom le test à la manière de: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

donc, à votre exemple:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Cependant, je ne préfère mettre le nom de la méthode testée d'abord, parce que les tests peuvent être classées par ordre alphabétique, ou apparaissent triés par ordre alphabétique dans le membre de la zone de liste déroulante dans VisStudio, et tous les tests pour la méthode 1 sont regroupés.


En tout cas, j'aime bien séparer les grandes sections de l'épreuve avec le nom " souligne, plutôt que chaque mot, parce que je pense qu'il est plus facile à lire et à obtenir le point de le tester sur.

En d'autres termes, comme je les aime: Sum_ThrowsException_WhenNegativeNumberAs1stParam de mieux qu' Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

22voto

Jehof Points 14720

Je n'nom de mes méthodes d'essai comme les autres méthodes à l'aide de "PascalCasing", sans traits de soulignement ou des séparateurs. Je laisse le suffixe de Test pour la méthode, la cause n'ajoute pas de valeur. Que la méthode est une méthode de test est indiqué par l'attribut TestMethod.

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

En raison du fait que chaque classe de Test ne devrait tester une autre classe, je laisse le nom de la classe sur le nom de la méthode. Le nom de la classe qui contient les méthodes de test est nommé comme la classe sous test avec le suffixe "Tests".

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

Pour les méthodes d'essai pour les exceptions ou des actions qui ne sont pas possible, je le préfixe de la méthode d'essai avec le mot Ne peut pas.

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

Mon nommage convension sont de base sur l'article "TDD Conseils: Test des Conventions de Nommage Et lignes Directrices" de Bryan Cuire. J'ai trouvé cet article très utile.

5voto

Frank Szczerba Points 2767

La première série de noms est plus lisible pour moi, depuis le CamelCasing sépare les mots et les underbars parties distinctes du schéma de nommage.

J'ai aussi tendance à inclure "Test" quelque part, soit dans le nom de la fonction ou de l'affichage de l'espace de noms ou de classe.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: