Je suis sûr que la plupart d'entre vous sont en écrivant beaucoup de tests automatisés et que vous avez également exécuter dans certains pièges courants lors de tests unitaires.
Ma question est pensez-vous suivez toutes les règles de conduite pour l'écriture de tests afin d'éviter des problèmes à l'avenir? Pour être plus précis: Quelles sont les propriétés de bons tests unitaires ou comment écrivez-vous vos tests?
Langue agnostique suggestions sont encouragés.
Permettez-moi de commencer par brancher des sources - Pragmatique de Tests Unitaires en Java avec JUnit (Il y a une version avec C#-Nunit trop.. mais j'ai celui-ci.. sa agnostique, pour la plupart. Recommandé).
De bons Tests devrait être UN VOYAGE (Le acronymn n'est pas assez collant - je avoir une impression de la triche dans le livre que j'avais pour s'en sortir assurez-vous que j'ai obtenu ce droit..)
Professionnel: Dans le long terme, vous aurez comme beaucoup de test de code de la production (si pas plus), donc de respecter la même norme de la bonne conception de votre code de test. Bien compte des méthodes de classes avec l'intention de révéler les noms, Pas de duplication, les tests avec les bons noms, etc.
Bon, les tests exécution Rapide. un test qui prend plus d'une demi-seconde pour exécuter.. doit être travaillé sur. Le plus de la suite de test prend pour une course.. le moins souvent, il sera exécuté. Le plus de changements de dev va essayer de se faufiler entre les courses. si quoi que ce soit casse.. il faudra plus de temps à comprendre que le changement était le coupable.
Mise à jour 2010-08:
En dehors de ces, la plupart des autres sont des lignes directrices qui coupe vers le bas sur le bas de la prestation de travail: par exemple, " Ne pas tester le code que vous ne possédez pas (par exemple, les Dll de tiers). N'allez pas sur le test de getters et setters. Gardez un œil sur le rapport coût-bénéfice ou d'un défaut de probabilité.
La plupart des réponses ici semblent l'adresse de l'unité de tester les meilleures pratiques en général (quand, où, pourquoi et quoi), plutôt qu'à écrire les tests eux-mêmes (comment). Puisque la question semble assez spécifique sur le "comment", je pensais que je poste ce, prises à partir d'un "brown bag" présentation que j'ai réalisée dans mon entreprise.
1. L'utilisation de long, descriptif de la méthode de test des noms.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Écrire vos tests dans un Arrangement/Act/Affirmer un style.
3. Toujours fournir un message d'échec avec vos Affirmations.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Commentaire la raison pour laquelle le test – quelle est l'hypothèse d'affaires?
/// 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()
{
}
5. Chaque test doit toujours revenir à l'état de toutes les ressources qu'il touche
Garder ces objectifs à l'esprit (adapté du livre xUnit des Modèles de Test par Meszaros)
Quelques trucs pour rendre cela plus facile:
N'oubliez pas que vous pouvez faire de l'insertion des tests avec votre xUnit cadre trop , mais garder l'insertion des tests unitaires et de tests distincts
Certaines propriétés d'une grande unité de tests:
Lorsqu'un test échoue, il doit être immédiatement évident de savoir où se trouve le problème. Si vous devez utiliser le débogueur pour traquer le problème, vos tests ne sont pas granulaire assez. Avoir exactement une affirmation par test permet ici.
Lorsque vous refactoriser, pas de tests doit échouer.
Les Tests doivent courir si vite que vous n'hésitez jamais à les exécuter.
Tous les tests doivent passer toujours; pas de non-déterministe résultats.
Les tests unitaires doivent être bien compte, tout comme votre code de production.
@Alotor: Si vous êtes suggérant qu'une bibliothèque ne devrait avoir que des tests unitaires à son API externe, je suis en désaccord. Je veux des tests unitaires pour chaque classe, y compris les classes que je ne l'exposez pas à des appelants externes. (Cependant, si je ressens le besoin d'écrire des tests pour les méthodes privées, alors j'ai besoin de refactoriser.)
EDIT: Il y avait un commentaire à propos de la duplication causée par "une affirmation par test". Plus précisément, si vous avez un peu de code pour définir un scénario, et que vous souhaitez faire plusieurs affirmations à ce sujet, mais seulement une affirmation par test, vous pouvez dupliquer l'installation à travers de multiples tests.
Je ne prends pas cette approche. Au lieu de cela, j'utilise des appareils de test par scénario. Voici un exemple grossier:
[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...
}
}
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.
