Utilizzo degli scenari Specflow per entrambi i test di integrazione e test delle unità

Question

Ho appena incontrato BBD e specflow e sembra molto interessante. Quando si scrivono storie di utenti, si tratta in genere di un livello elevato e gli utenti dell'attore della GUI. Pertanto, quando si scrivono gli scenari, si tratta in genere di test della GUI o di integrazione da un livello elevato del sistema. Ma per quanto riguarda il test unitario più avanti nella soluzione? Per esempio. endpoint del servizio, oggetti business, ecc. Devo scrivere nuovi scenari per questi o esiste un modo per riutilizzare gli stessi scenari per i test di basso livello (unit test) o dovrei copiare e superare gli scenari?

Per favore fatemi sapere se ho sbagliato tutto.

Answer 1

I framework BDD come SpecFlow sono progettati per aiutare i membri del team tecnico a comunicare più facilmente con gli stakeholder non tecnici di un progetto.

Le specifiche in lingua inglese non sono facili da mantenere o refactoring. Poiché le uniche persone che leggono i test o gli esempi a livello di unità sono tecnici e in grado di leggere il codice, preferisco utilizzare framework di test unitari come NUnit a quel livello.

Gli scenari hanno spesso molta più complessità rispetto ai test unitari. Normalmente trovo che coprano una serie di combinazioni di logica aziendale interna, e ogni aspetto che costituisce una combinazione sarà responsabilità di una diversa unità di codice. La logica degli scenari verrà quindi suddivisa tra un numero di test unitari diversi e non sarà possibile copiarli.

A volte utilizzo gli scenari per guidare i test dell'unità. Potrei scoprire che un po 'di logica finisce per essere la responsabilità di una particolare unità di codice, e quindi posso copiare solo i passi rilevanti dallo scenario nei test unitari come commento.

// 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)); 

vi incoraggio a copiare la lingua in cui sono scritti gli scenari (ad esempio: PayOut). Questo è in linea con il "linguaggio onnipresente" di Domain Driven Design. Portare quella lingua in entrambi i test unitari e il codice aiuta anche una squadra a dialogare con le parti interessate, perché non dovrai eseguire la traduzione più e più volte.

L'inserimento di dati/quando/poi nei commenti mi aiuta anche a concentrarmi sulla consegna del codice che verrà effettivamente utilizzato, invece di cercare di indovinare tutti i casi limite. Il codice di migliore qualità è il materiale che non hai non scrivere.

Buona fortuna!