Test d'unité de meilleures pratiques

Question

Quelles sont les meilleures pratiques pour la désignation de l'unité de classes de test et les méthodes d'essai?

Cela a été discuté sur SI avant, à Ce que certains populaire conventions de nommage pour les Tests Unitaires?

Je ne sais pas si c'est une très bonne approche, mais actuellement, dans mes projets, j'en ai un-à-un les mappages entre chaque production de la classe et une classe de test, par exemple, Product et ProductTest.

Dans mes classes de test je puis disposer de méthodes avec les noms des méthodes, je suis en train de tester, un trait de soulignement, et puis la situation et ce que j'attends d'arriver, par exemple, Save_ShouldThrowExceptionWithNullName().

Answer 1

J'aime Roy Osherove de la stratégie de nommage, 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 petit qu'une seule méthode, une classe ou aussi grand que plusieurs classes. Il doit représenter toutes les choses qui doivent être testés dans ce cas de test et sont sous contrôle.

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

[NameOfTheClassUnderTestTests]

Précédemment, j'ai utilisé le Luminaire au suffixe au lieu de Tests, mais je pense que le dernier est plus commun, puis j'ai changé la stratégie de nommage.

Answer 2

J'aime suivre le "Doit" standard de nommage pour les tests en nommant le montage de test, après que l'unité sous test (c'est à dire la classe).

Pour illustrer (C# + 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 "Doit"?

Je trouve qu'il force le test des écrivains pour nom le test avec une phrase du genre "Faut être dans un certain état] [après/avant/lorsque] [action]"

Oui, l'écriture "Devrait" partout ne obtenir un peu répétitif, mais comme je l'ai dit il oblige les auteurs à penser dans le bon sens (donc peut être bon pour les novices). Plus il en résulte généralement dans un anglais lisible nom de test.

Mise à jour:

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

Answer 3

J'aime ce style de nommage:

 OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();
 

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

Answer 4

Kent Beck suggère:

• Un montage de test par "unité" (classe de votre programme). Appareils de Test sont des classes elles-mêmes. Le montage de test, le nom doit être:

  [nom de votre "unité"] Tests

• Des cas de Test (le test fixture méthodes) ont des noms comme:

  test[fonctionnalité testée]

Par exemple, la classe suivante:

class Person {

    int calculateAge() { ... }

    // other methods and properties
}

Un montage de test serait:

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Answer 5

Les Noms De Classe. Pour le montage de test, les noms, je trouve que le "Test" est assez commun dans l'omniprésence de la langue de nombreux domaines. Par exemple, dans un domaine du génie: StressTest, et dans les produits de beauté de domaine: SkinTest. Désolé d'être en désaccord avec le Kent, mais à l'aide de "Test" dans mes appareils de test (StressTestTest?) c'est déroutant.

"Unité" est également utilisé dans de nombreux domaines. E. g. MeasurementUnit. Est une classe appelée MeasurementUnitTest un test de la "Mesure" ou "MeasurementUnit"?

Par conséquent, je tiens à utiliser le "Qa" préfixe pour toutes mes classes de test. E. g. QaSkinTest et QaMeasurementUnit. Il n'est jamais confondu avec des objets du domaine, et à l'aide d'un préfixe plutôt que d'un suffixe qui signifie que tous les appareils de test vivre ensemble visuellement (utile si vous avez de faux ou d'autres classes de soutien dans votre projet de test)

Les espaces de noms. Je travaille en C# et je continue mon test de classes dans le même espace de nom que la classe, elles sont à l'essai. Il est plus pratique que d'avoir un test d'espaces de noms. Bien sûr, les classes de test sont dans un autre projet.

La méthode d'essai noms. J'aime le nom de mes méthodes WhenXXX_ExpectYYY. Il rend la condition clair, et contribue à la documentation automatique (à la TestDox). Ceci est similaire à l'avis sur le Google blog de tests, mais avec plus de séparation de conditions préalables et les attentes. Par exemple:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory