Utilisation de scénarios Specflow pour les tests d'intégration et les tests unitaires

Question

Je viens de rencontrer BBD et specflow et cela semble très intéressant. Lors de la rédaction d'histoires d'utilisateurs, ils sont généralement de haut niveau et l'utilisateur utilise l'interface graphique. Donc, lors de l'écriture des scénarios, ils seront généralement test de GUI ou test d'intégration à partir d'un niveau élevé du système. Mais qu'en est-il du test unitaire plus bas dans la solution? Par exemple. Je devrais écrire de nouveaux scénarios pour ceux-ci ou existe-t-il un moyen de réutiliser les mêmes scénarios pour les tests de bas niveau (tests unitaires) ou devrais-je copier et dépasser les scénarios?

S'il vous plaît laissez-moi savoir si j'ai tout faux.

Answer 1

Les frameworks BDD comme SpecFlow sont conçus pour aider les membres de l'équipe technique à communiquer plus facilement avec les parties prenantes non techniques d'un projet.

Les spécifications en anglais ne sont pas faciles à maintenir ou à refactoriser. Comme les seules personnes qui lisent des tests ou des exemples au niveau de l'unité sont techniques et capables de lire du code, je préfère utiliser des frameworks de tests unitaires tels que NUnit à ce niveau.

Les scénarios comportent souvent beaucoup plus de complexité que les tests unitaires. Normalement, je trouve qu'ils couvrent un certain nombre de combinaisons de logique métier interne, et chaque aspect qui compose une combinaison sera la responsabilité d'une unité de code différente. La logique des scénarios sera donc répartie entre plusieurs tests unitaires différents, et vous ne pourrez pas les copier.

Parfois, j'utilise les scénarios pour guider mes tests unitaires. Je pourrais trouver qu'un peu de logique finit par être la responsabilité d'une unité particulière de code, et alors je peux copier seulement les étapes pertinentes du scénario dans les tests unitaires comme un commentaire.

// Given I have $100 in my account 
var account = new Mock<Account>(); 
account.SetupGet(a => a.Balance).Returns(100); 

var accountProvider = new Mock<AccountProvider>(); 
accountProvider.Setup(ap => ap.AccountFor("lunivore")).Returns(account); 

// When I ask for $20 
var atm = new ATM(accountProvider); 
atm.PutInCardFor("lunivore"); 
int money = atm.RequestMoney(20); 

// Then I should get $20 
Assert.AreEqual(20, money); 

// And my account should have paid out $20 
account.verify(a => a.PayOut(20)); 

Je vous encourage à copier la langue dans laquelle les scénarios sont écrits (par exemple: PayOut). Ceci est aligné avec le «langage omniprésent» de Domain Driven Design. Transporter ce langage à la fois dans les tests unitaires et dans le code aide également une équipe à dialoguer avec les parties prenantes, car vous n'aurez pas à faire la traduction encore et encore. L'ajout de Given/When/Then dans les commentaires m'aide aussi vraiment à me concentrer sur la livraison du code qui va réellement être utilisé, au lieu d'essayer de deviner tous les cas de bords. Le meilleur code de qualité est la substance que vous n'écrivez pas.

Bonne chance!