Est-ce une bonne pratique d'utiliser RowTest dans un test unitaire

Question

NUnit et MbUnit ont un attribut RowTest qui vous permet d'envoyer différents ensembles de paramètres en un seul test.

[RowTest] 
[Row(5, 10, 15)] 
[Row(3.5, 2.7, 6.2)] 
[Row(-5, 6, 1)] 
public void AddTest(double firstNumber, double secondNumber, double result) 
{ 
    Assert.AreEqual(result, firstNumber + secondNumber); 
} 

J'avais l'habitude d'être un grand fan de cette fonctionnalité. Je l'ai utilisé partout. Cependant, dernièrement, je ne suis pas sûr que ce soit une très bonne idée d'utiliser RowTest dans Unit Tests. Voici d'autres raisons:

Un test unitaire doit être très simple. S'il y a un bug, vous ne voulez pas passer beaucoup de temps à comprendre ce que votre test teste. Lorsque vous utilisez plusieurs lignes, chaque ligne a un ensemble de paramètres différent et teste quelque chose de différent.

Aussi j'utilise TestDriven.NET, qui me permet d'exécuter mes tests unitaires à partir de mon IDE, Visual Studio. Avec TestDrivent.NET je ne peux pas ordonner d'exécuter une ligne spécifique, il va exécuter toutes les lignes. Par conséquent, lorsque je débogue, je dois commenter toutes les autres lignes et ne laisser que celle avec laquelle je travaille.

Voici un exemple comment écrirait mes tests aujourd'hui:

[Test] 
public void Add_with_positive_whole_numbers() 
{ 
    Assert.AreEqual(5, 10 + 15); 
} 

[Test] 
public void Add_with_one_decimal_number() 
{ 
    Assert.AreEqual(6.2, 3.5 + 2.7); 
} 

[Test] 
public void Add_with_negative_number() 
{ 
    Assert.AreEqual(1, -5 + 6); 
} 

Dire que je l'utilise encore parfois attribut RowTest mais seulement quand je crois que ça ne va pas me ralentir quand je dois travailler plus tard .

Pensez-vous que c'est une bonne idée d'utiliser cette fonctionnalité dans un test unitaire?

Answer 1

Oui. Il s'agit essentiellement d'exécuter le même test encore et encore avec différentes entrées ... vous évitant ainsi de devoir vous répéter pour chaque combinaison d'entrée distincte.
Ainsi confirmant le 'une fois et une seule fois' ou le principe DRY. Donc, si vous avez besoin de mettre à jour ce test, vous n'avez qu'à mettre à jour un test (vs plusieurs). Chaque ligne doit être une entrée représentative d'un ensemble distinct, c'est-à-dire que cette entrée est différente de toutes les autres. le comportement de cette fonction. Le RowTest était en fait une fonctionnalité très demandée pour NUnit - ayant pour origine MBUnit ... Je pense que Schlapsi l'a écrit comme une extension NUnit qui a ensuite été promue au statut de distribution std. L'interface graphique de NUnit regroupe également toutes les RowTests sous un nœud dans l'interface graphique et montre quelle entrée a échoué/a passé. Ce qui est cool. Le désavantage mineur du 'besoin de déboguer' est quelque chose que je peux vivre personnellement .. C'est après tout commentant temporairement un certain nombre d'attributs de Row (d'abord la plupart du temps je peux regarder la fonction une fois que je trouve ScénarioX échoué et le résoudre sans avoir besoin d'un step-through) ou inversement il suffit de copier le test et passer les entrées fixes (problématiques) temporairement