J'espère que cela ne rencontre pas comme une question stupide mais c'est quelque chose que je me demandais. Je souhaite écrire un test de l'unité une méthode contenant une certaine logique pour vérifier que certaines valeurs ne sont pas nuls.
[TestMethod]
public void TestMyMethodWithNullValues()
{
//pass null for value1
//check
//pass null for value2
//check
}
4 Réponses :
Vous devez écrire un test d'unité
Si vous effectuez deux tests dans la même méthode de test, vos tests ne font pas "test-test".
Par exemple, que se passe-t-il si le test pour le premier D'autre part, si vous avez deux méthodes de test distinctes, vous pouvez tester chaque cas dans une isolation parfaite.
Ainsi: vous devez utiliser deux tests distincts. NULL La valeur échoue?
Si les deux tests sont dans la même méthode de test, le deuxième test ne sera probablement pas exécuté; Ce qui signifie que le test sur la deuxième valeur NULL NULL dépend du test sur la valeur NULL NULL .
Juger du code de votre MyMethod , il n'y a pas de lien entre les deux conditions; ce qui signifie qu'il ne devrait probablement pas y avoir de dépendance entre les tests pour ces deux conditions.
Même si vous regroupez vos tests, votre unité de code à tester est toujours la même - c'est donc un test d'unité encore, quoi que ce soit: o) Mais ce que vous perdez progressivement, c'est la capacité à identifier l'échec. En pratique, il s'agit d'un compromis entre beaucoup de tests (= beaucoup de syntaxe) vs aptitude à identifier - voir la réponse de Michael.
Le test de test de l'unité "idéal" Une seule chose uniquement pour identifier les erreurs exactement.
En pratique, ce n'est pas aussi important que l'état de la plupart des partisans TDD, car les tests ne font pas échouer fréquemment et que l'affirmation a échoué ne prend presque pas de temps comparé au reste des travaux impliqués dans l'enquête et la fixation du problème. .
Faire des travaux supplémentaires lors de la rédaction des tests pour vous épargner du travail quand il échoue (qui peut ne jamais arriver) est une forme de Yagni .
Si avoir plusieurs méthodes n'est pas un travail supplémentaire au-delà de la frappe plus de déclarations de méthodes, vous devez le faire, mais s'il conduit à un code de configuration dupliqué, je ne vois absolument rien de mal à tester plusieurs conditions dans une méthode de test.
extrapoler à une pensée non technique.
Dites que vous avez une voiture et que vous voulez tester la couleur.
Les tests peuvent être:
voiture est rouge. La voiture est bleue. La voiture est peinte.
Maintenant, cela pourrait être logique d'avoir "peint" et "bleu", mais ils sont vraiment des choses différentes. Et si vous testez le rouge et le bleu, cela échouera toujours - ou l'échec n'aurait pas de sens d'un point de vue d'isolement.
Testez toujours une chose à la fois comme vous le suggérez et de nombreuses choses comprennent la suite de tests.
Ce n'est pas une règle; C'est un appel de jugement. Si le test est évident et lisible, une seule fonction va bien. Sinon, divisez-les pour lisibilité .