VB.NET et NUnit - TDD

Question

J'apprends TDD avec VB.NET et NUnit. Je veux savoir quelle est la meilleure chose à faire: Utiliser beaucoup de méthodes Assert à l'intérieur d'une méthode de test ou utiliser un assert par méthode?

Ceci est mon code. Je vous remercie.

Imports NUnit.Framework 

<TestFixture()> _ 
Public Class CalculatorTest 
<Test()> _ 
Public Sub TestAdd() 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(2, calculator.sum(1, 1)) 
    Assert.AreNotEqual(3, calculator.sum(2, 2)) 
    Assert.AreEqual(-1, calculator.sum(0, -1)) 
     Assert.AreNotEqual(3, calculator.sum(1, 1)) 
    End Sub 
End Class 

Answer 1

La «meilleure pratique» généralement acceptée est un assertion par test. (Selon Roy Osherove)

Cependant, ce test particulier peut être fait un peu plus simplement avec NUnit en utilisant TestCases:

<Test()> _ 
<TestCase(1, 1, 2)> _ 
<TestCase(1,-1, 0)> _ 
<TestCase(0,-1,-1)> _ 
Public Sub Calculator_Add_ReturnsExpectedResult(Integer a, Integer b, Integer expected) 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(expected, calculator.sum(a, b)) 
End Class 

Notez également la dénomination je là, afin de préciser exactement ce que le test est en train de tester. Le principe derrière la pratique "Un Assert par Test" est que vous voulez qu'un test échoué signifie quelque chose de très spécifique. Autrement dit, chaque test devrait vous dire si une seule chose spécifique fonctionne.

Answer 2

Ceci est un débat intéressant, et peut descendre à une question de style. J'aime l'opinion de Roy Osherove, à savoir que vous ne devriez avoir qu'un seul test par test unitaire. Lire la discussion approfondie de ce numéro here.

En outre, vérifiez this sur.

Answer 3

Une meilleure façon d'y penser est de tester une chose à la fois. Utilisez autant d'affirmations que nécessaire pour tester cette chose, mais généralement une seule. Plusieurs affirmations peuvent être un signe que vous testez plus d'une chose à la fois, mais ce n'est pas, à mon avis, une règle absolue. Le meilleur guide est que vous ne voulez pas créer de dépendances dans vos tests entre des concepts indépendants.

Dans votre exemple, vous êtes en train de tester 4 choses, bien que vous n'en ayez probablement besoin que deux car elles couvrent le même terrain. Je suggère de tester ce qui se passe quand vous ajoutez deux nombres positifs, deux nombres négatifs, et un négatif et un positif avec des résultats négatifs et positifs. Ensuite, je pense aux propriétés mathématiques et à la commutativité des tests et à l'identité additive (zéro). Enfin, je testerais les conditions aux limites - débordement positif et négatif, etc. Notez, ceci peut être ou ne pas être complet, c'est-à-dire, je pense avoir couvert les bases, mais je n'essaie pas trop d'être exhaustif ; Je veux juste illustrer comment vous pourriez penser à quels tests écrire et, oui, je ferais chacun de ces tests séparés avec un seul assertion. Pour quelque chose de plus complexe, vous pouvez avoir plus d'un assert qui teste la même "chose" - par exemple, vous pouvez vouloir vérifier qu'une ligne est correctement insérée dans le DB avec un ensemble donné d'entrées. Je pense qu'il est parfaitement acceptable de tester que toutes les colonnes ont leur propre valeur dans un seul test, plutôt que de tester chaque propriété individuellement. D'autres peuvent différer, mais je ne pense pas que dans ce cas vous créez des dépendances en testant que toutes les propriétés ont leurs valeurs correctes car l'insertion est une action atomique.

Answer 4

Le point de vue d'Osherove fait penser à l'intégrisme. Par exemple, si une fonction renvoie une structure/classe, vous devrez soit utiliser plusieurs assertions, soit créer une structure personnalisée en comparant assert, ce qui fait vraiment la même chose.

L'important est de tester ce que la fonctionnalité fait. Et peut-être de toujours interroger "les experts".