Quelles sont les conventions de dénomination les plus courantes pour les tests unitaires ?

Question

Général

• Suivre les mêmes normes pour tous les tests.
• Soyez clair sur la nature de chaque état de test.
• Soyez précis quant au comportement attendu.

Exemples

1) Nom de la méthode_État testé_Comportement attendu

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

Source : Nommer les normes pour les tests unitaires

2) Séparer 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 ()

Autres

• Les noms de méthodes se terminent par Test
• Commencer les noms de méthodes par le nom de la classe

Answer 1

Je suis à peu près d'accord avec vous sur ce point. Les conventions de dénomination que vous avez utilisées sont les suivantes

• Préciser clairement ce qu'est chaque état d'essai.
• Préciser le comportement attendu.

Que demander de plus à un nom de test ?

Contrairement à Réponse de Ray Je ne pense pas que la Test est nécessaire. Il s'agit d'un code de test, nous le savons. Si vous avez besoin de faire cela pour identifier le code, alors vous avez de plus gros problèmes, votre code de test ne doit pas être mélangé avec votre code de production.

En ce qui concerne la longueur et l'utilisation du trait de soulignement, son code de test qui s'en soucie ? Seuls vous et votre équipe le verrez, tant qu'il est lisible et clair sur ce que fait le test, continuez ! :)

Cela dit, je suis encore un peu novice en matière de tests et d'essais. bloguer mes aventures avec elle :)

Answer 2

Cela vaut également la peine d'être lu : Structurer les tests unitaires

La structure comporte une classe de test par classe testée. Ce n'est pas si inhabituel. Mais ce qui m'a semblé inhabituel, c'est qu'il y 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 :

D'une part, c'est un bon moyen d'organiser les tests. Tous les tests (ou faits) d'une méthode sont regroupés. Par exemple, si vous utilisez les raccourcis CTRL+M, CTRL+O pour réduire les corps des méthodes, vous pouvez facilement analyser vos tests et les lire comme une spécification de votre code.

J'aime aussi cette approche :

MethodName_StateUnderTest_ExpectedBehavior (Nom de la méthode)

Il faut donc peut-être s'adapter :

Comportement attendu de l'État sous test

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

Answer 3

J'ai tendance à utiliser la convention suivante MethodName_DoesWhat_WhenTheseConditions Ainsi, par exemple :

Sum_ThrowsException_WhenNegativeNumberAs1stParam

Cependant, ce que je vois souvent, c'est que le nom du test suit la structure de test unitaire de

• Organiser
• Agir
• Affirmer

Ce qui suit également la syntaxe BDD / Gherkin de :

• Données
• Quand
• Dans ce cas

qui consisterait à nommer le test à la manière de : UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

pour reprendre votre exemple :

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

Cependant, je préfère de loin placer le nom de la méthode testée en premier, car les tests peuvent alors être classés par ordre alphabétique, ou apparaître triés par ordre alphabétique dans la liste déroulante des membres de VisStudio, et tous les tests d'une méthode sont regroupés.

---

Quoi qu'il en soit, j'aime bien séparer les principales sections du nom du test avec des traits de soulignement, contrairement à chaque mot Je pense que cela facilite la lecture et permet de faire passer l'idée du test.

En d'autres termes, j'aime : Sum_ThrowsException_WhenNegativeNumberAs1stParam mieux que Sum_Throws_Exception_When_Negative_Number_As_1st_Param .

Answer 4

Je nomme mes méthodes de test comme les autres méthodes en utilisant "PascalCasing" sans soulignement ni séparateur. Je laisse le postfixe Test pour la méthode out, car elle n'apporte aucune valeur ajoutée. Le fait que la méthode soit une méthode de test est indiqué par l'attribut Méthode de test .

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

Étant donné que chaque classe de test ne doit tester qu'une seule autre classe, je ne mentionne pas le nom de la classe dans le nom de la méthode. Le nom de la classe qui contient les méthodes de test est nommé comme la classe testée avec le postfixe "Tests".

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

Pour les méthodes qui testent des exceptions ou des actions qui ne sont pas possibles, je fais précéder la méthode de test du mot Ne peut pas .

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

Mes conventions d'appellation sont basées sur l'article "Conseils TDD : Conventions de dénomination des tests et lignes directrices" de Bryan Cook. J'ai trouvé cet article très utile.

Answer 5

La première série de noms me semble plus lisible, car la casse camélienne sépare les mots et les barres inférieures séparent les parties du système de dénomination.

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