BDD/TDD mocking dei dati in modo ingannevole

Question

Quindi un collega e io siamo in un dibattito piuttosto acceso. Stiamo iniziando un nuovo progetto e stiamo tentando di utilizzare BDD. Siamo entrambi principianti e non comprendiamo appieno le pratiche da utilizzare. Abbiamo scritto alcune specifiche e ora stiamo implementando il codice. Le cose stanno diventando piuttosto complicate dal momento che c'è molta interazione con il database. Siamo bloccati su come dovremmo prendere in giro i nostri dati. Il metodo che stavamo facendo avrebbe richiesto di prendere in giro i nostri metodi invece dei nostri dati. E 'più facile se vi mostro in codice ...

public static void AssignLeadToDistributor(int leadId, int distributorId) 
{ 
    Lead lead = GetById(leadId); 
    lead.DistributorId = distributorId; 
    Save(lead); 
} 

In sostanza, dovremmo ignorare GetById() e Save() per restituire i dati finte per mettere alla prova questo. Sembra avere più senso di farlo in questo modo:

public static void AssignLeadToDistributor(Lead lead, Distributor distributor) 
{ 
    lead.DistributorId = distirbutor.Id; 
} 

allora potremmo semplicemente prendere in giro i nostri oggetti.

Chiaramente il secondo metodo facilita il test. Tuttavia, l'argomento è che non vogliamo dover recuperare un nuovo oggetto lead e distributore sul nostro front-end, perché sarebbe più semplice passare semplicemente gli id ​​dei nostri oggetti. Ridurre il codice effettivo nel nostro front-end.

Spero di averlo spiegato abbastanza bene.

Cosa ne pensate? Quale strada ha più senso?

Answer 1

Quello che facciamo nelle nostre specifiche BDD (storie eseguibili), è di non deridere affatto il DB, ma invece di utilizzare un DB in memoria (SQLite nel nostro caso).

Inoltre, inizializziamo il contenitore prima che venga eseguito qualsiasi scenario. Questo perché vorremmo che le nostre specifiche BDD imitassero il mondo reale il più lontano possibile, pur mantenendo la velocità dei test unitari ordinari.

Definendo le nostre specifiche BDD in questo modo, abbiamo riscontrato la necessità di ridurre i test unitari e di integrazione e ottenere sia maggiore produttività che comprensibilità (sebbene molto soggettivo poiché non è possibile misurare realmente tali metriche).

Answer 2

Penso che il problema più grande che si sta avendo è che si utilizzano funzioni pubbliche statiche (che di solito è una cosa negativa nelle lingue OO).

Io suggerirei di spostare questa funzione all'oggetto di piombo, qualcosa come

public AssignDistributor(int distributorId) { 
    this.DistributorId = distributorId; 
    this.Save(); 
} 

Più facile da testare, e più codice OO-like =)

Answer 3

Mi piace il secondo metodo migliore, per la ragione per cui hai affermato: puoi simulare facilmente i parametri per il test. Stai usando un'infrastruttura per le dipendenze? Altrimenti, ti consiglierei di programmare i tuoi metodi usando comunque il principio di dipendenza dalle dipendenze per un codice più modulare e facile da testare.

E sono d'accordo con Samuel sul fatto che è necessario evitare l'uso di metodi statici ogni volta che sia possibile, o sarà molto difficile testarli.