Question Test d'unité de meilleures pratiques de dénomination [fermé]


Quelles sont les meilleures pratiques pour nommer les classes de tests unitaires et les méthodes de test?

Cela a été discuté sur SO avant, à Quelles sont les conventions de dénomination populaires pour les tests unitaires?

Je ne sais pas si c'est une très bonne approche, mais actuellement dans mes projets de test, j'ai des correspondances individuelles entre chaque classe de production et une classe de test, par ex. Product et ProductTest.

Dans mes classes de test, j'ai ensuite des méthodes avec les noms des méthodes que je suis en train de tester, un trait de soulignement, puis la situation et ce que je m'attends à faire, par ex. Save_ShouldThrowExceptionWithNullName().


415
2017-09-30 22:44


origine


Réponses:


J'aime La stratégie de nommage de Roy Osherove, c'est le suivant:

[UnitOfWork__StateUnderTest__ExpectedBehavior]

Il a toutes les informations nécessaires sur le nom de la méthode et de manière structurée.

L'unité de travail peut être aussi petite qu'une méthode unique, une classe ou une classe aussi grande que plusieurs. Il devrait représenter toutes les choses qui doivent être testées dans ce cas de test et sont sous contrôle.

Pour les assemblages, j'utilise le typique .Tests la fin, qui je pense est assez répandue et la même pour les classes (se terminant par Tests):

[NameOfTheClassUnderTestTests]

Auparavant, j'ai utilisé Fixture comme suffixe au lieu de tests mais je pense que ce dernier est plus commun, puis j'ai changé la stratégie de nommage.


390
2017-10-20 11:47



J'aime suivre le "Devrait" norme de nommage pour tests en nommant le appareil d'essai après l'unité sous test (c'est-à-dire la classe).

Pour illustrer (en utilisant C # et NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

Pourquoi "Devrait"?

Je trouve que cela oblige les auteurs de tests à nommer le test avec une phrase du type "Doit [être dans un état] [après / avant / quand] [l'action a lieu]"

Oui, écrire "Should" partout devient un peu répétitif, mais comme je l'ai dit, cela oblige les écrivains à penser de la bonne manière (ce qui peut être bon pour les novices). De plus, cela se traduit généralement par un nom de test anglais lisible.

Mettre à jour:

J'ai remarqué que Jimmy Bogard est aussi un fan de 'devrait' et a même une bibliothèque de tests unitaires appelée Devrait.

Mise à jour (4 ans plus tard ...)

Pour les personnes intéressées, mon approche des tests de nommage a évolué au fil des ans. L'un des problèmes avec Devrait modèle que je décris ci-dessus car il n'est pas facile de savoir en un coup d'oeil quelle méthode est en cours de test. Pour la POO, je pense qu'il est plus logique de commencer le nom du test avec la méthode testée. Pour une classe bien conçue, cela devrait aboutir à des noms de méthodes de test lisibles. J'utilise maintenant un format similaire à <method>_Should<expected>_When<condition>. Évidemment, en fonction du contexte, vous pouvez remplacer les verbes Should / When par quelque chose de plus approprié. Exemple: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()


71
2017-09-13 08:01



J'aime ce style de nommage:

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

etc. Il est très clair pour un non-testeur quel est le problème.


65
2017-09-30 22:56



Kent Beck suggère:

  • Un appareil d'essai par 'unité' (classe de votre programme). Les appareils de test sont eux-mêmes des classes. Le nom du banc d'essai doit être:

    [name of your 'unit']Tests
    
  • Les cas de test (les méthodes de test) ont des noms tels que:

    test[feature being tested]
    

Par exemple, ayant la classe suivante:

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

Un appareil d'essai serait:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

44
2017-09-30 22:54



Noms de classe. Pour les noms d'appareils de test, je trouve que "Test" est assez commun dans le langage omniprésent de nombreux domaines. Par exemple, dans un domaine d'ingénierie: StressTestet dans un domaine cosmétique: SkinTest. Désolé d'être en désaccord avec Kent, mais en utilisant "Test" dans mes appareils de test (StressTestTest?) prête à confusion.

"Unit" est aussi beaucoup utilisé dans les domaines. Par exemple. MeasurementUnit. Est-ce qu'une classe s'appelle MeasurementUnitTest un test de "Measurement" ou "MeasurementUnit"?

Par conséquent, j'aime utiliser le préfixe "Qa" pour toutes mes classes de test. Par exemple. QaSkinTest et QaMeasurementUnit. Il n'est jamais confondu avec les objets du domaine, et l'utilisation d'un préfixe plutôt que d'un suffixe signifie que tous les équipements de test cohabitent visuellement (utile si vous avez des faux ou d'autres classes de support dans votre projet de test)

Espaces de noms. Je travaille en C # et je garde mes classes de test dans le même espace de noms que la classe qu'ils testent. C'est plus pratique que d'avoir des espaces de noms de test séparés. Bien sûr, les classes de test sont dans un projet différent.

Noms des méthodes de test. J'aime nommer mes méthodes WhenXXX_ExpectYYY. Cela clarifie la précondition et aide à la documentation automatisée (à la TestDox). Ceci est similaire au conseil sur le blog de test de Google, mais avec plus de séparation des conditions préalables et des attentes. Par exemple:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

16
2017-10-10 23:09



Voir: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html

Pour les noms de méthodes de test, je trouve personnellement que l'utilisation de noms verbeux et auto-documentés est très utile (parallèlement aux commentaires de Javadoc qui expliquent davantage ce que fait le test).


8
2017-09-30 22:53



Je suis récemment venu avec la convention suivante pour nommer mes tests, leurs classes et contenir des projets afin de maximiser leurs descriptivenes:

Disons que je teste le Paramètres classe dans un projet dans le MyApp.Serialization espace de nommage.

D'abord je vais créer un projet de test avec le MyApp.Serialization.Tests espace de nommage.

Dans ce projet et bien sûr l'espace de noms je vais créer une classe appelée IfSettings (enregistré sous IfSettings.cs).

Disons que je teste le SaveStrings () méthode. -> Je vais nommer le test CanSaveStrings ().

Lorsque je lance ce test, il affiche le titre suivant:

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

Je pense que cela me dit très bien ce que c'est de tester.

Bien sûr, il est utile qu'en anglais le nom "Tests" soit le même que le verbe "tests".

Il n'y a pas de limite à votre créativité en nommant les tests, de sorte que nous obtenons des titres complets pour eux.

Habituellement, les noms de test doivent commencer par un verbe.

Les exemples comprennent:

  • Détecte (par exemple DetectsInvalidUserInput)
  • Lance (par exemple, ThrowsOnNotFound)
  • Will (par exemple WillCloseTheDatabaseAfterTheTransaction)

etc.

Une autre option consiste à utiliser "that" au lieu de "if".

Ce dernier me sauve des frappes et décrit plus exactement ce que je fais, puisque je ne sais pas, cette le comportement testé est présent, mais je teste si c'est.

[modifier]

Après avoir utilisé la convention de nommage ci-dessus pour un peu plus longtemps maintenant, j'ai trouvé, que le Si préfixe peut être déroutant, lorsque vous travaillez avec des interfaces. Il se trouve juste que la classe de test IfSerializer.cs ressemble beaucoup à l'interface ISerializer.cs dans l'onglet "Ouvrir les fichiers". Cela peut devenir très agaçant lors des allers-retours entre les tests, la classe testée et son interface. En conséquence, je voudrais maintenant choisir Cette plus de Si en préfixe

De plus, j'utilise maintenant - uniquement pour les méthodes dans mes classes de test car cela n'est pas considéré comme la meilleure pratique ailleurs - le "_" pour séparer les mots dans les noms de mes méthodes de test comme dans:

  • [Test] public void detects_invalid_User_Input () *

Je trouve que c'est plus facile à lire.

[Fin Modifier]

J'espère que cela suscitera encore plus d'idées, car je considère que nommer des tests de grande importance car cela peut vous faire économiser beaucoup de temps qui aurait autrement été dépensé en essayant de comprendre ce que les tests font (par exemple, après avoir interrompu un projet) .


6
2018-06-18 18:59