Come utilizzare i test unitari quando si utilizza BDD?

Lo sviluppo orientato al comportamento e lo sviluppo orientato ai test sono gratuiti, ma non sostituiscono l'uno con l'altro.

L'applicazione "si comporta" è descritta in Test di accettazione, che secondo BDD sarebbero le caratteristiche e gli scenari scritti in Cucumber.

I dettagli nitidi di come funziona ogni piccolo componente sono descritti in Test unitari. I risultati dei Test unitari supportano gli Scenari che scrivi in Cucumber.

Immagina il processo per la costruzione di un'auto.

In primo luogo, il team del prodotto presenta le loro idee e infine le riduce a scenari di utilizzo:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

So che questo scenario sembra un po 'sciocco, ma è un requisito molto focalizzato su prodotti e utenti finali. Basta aprire la porta, girare la chiave e avviare il motore comporta un sacco di diversi componenti che lavorano insieme. Questo test non è sufficiente per assicurarsi che il veicolo funzioni correttamente. È necessario testare il motorino di avviamento, la batteria, l'alternatore, la chiave, l'interruttore di accensione --- e l'elenco si accende --- solo per salire in macchina e avviarlo. Ognuno di questi componenti ha bisogno dei propri test.

Lo scenario sopra riportato è un test "Immagine grande". Ogni componente del veicolo necessita di test "Small Picture" per assicurarsi che funzionino correttamente all'interno di tutto.

Costruire e testare il software è lo stesso sotto molti aspetti. Si progetta dall'alto verso il basso, quindi si costruisce dal basso verso l'alto. Perché una porta che si alza se non riesci nemmeno ad avviare il motore? Perché avere un dispositivo d'avviamento se non si ha la batteria?

Il tuo team di prodotto presenterà i Test di accettazione e li arricchirà in Cucumber. Questo ti dà il "Big Picture". Ora spetta al team di ingegneri progettare i componenti corretti e il loro modo di interagire, quindi testarli separatamente - questi sono i test delle unità.

Una volta superati i Test unitari, inizia ad implementare gli scenari Cucumber. Una volta che passano, hai consegnato ciò che il team del prodotto ha chiesto.

I am trying to understand BDD. I've read some articles and as I understood BDD is "the next step" from TDD. I say that because I find both to be very similar, and as I could read in this article, BDD was born as an improvement from TDD.

In realtà, no, BDD è non "il prossimo passo" da TDD. È è TDD. O più precisamente, è una riformulazione di TDD.

I creatori di BDD hanno notato che l'ostacolo principale alla comprensione del fatto che TDD non riguarda i test ma le specifiche comportamentali era che tutta la terminologia TDD riguarda il testing e non le specifiche comportamentali. È come cercare di non pensare ad un elefante rosa quando qualcuno ti dice "cerca di non pensare ad un elefante rosa", eccetto con l'ulteriore complicazione di essere in una stanza piena di elefanti rosa e un ragazzo che urla costantemente "elefante rosa, rosa elefante, elefante rosa "nel tuo orecchio.

Quindi, hanno riformulato il TDD in termini di specifiche comportamentali. "Test" e "casi di test" sono ora "esempi", "unità" sono "comportamenti", "asserzioni" sono "aspettative" e così via.

Tuttavia, la metodologia è sempre la stessa. Si inizia con un test di accettazione (intendo "feature"), zoom in su un test di unità (intendo "esempio"), zoom indietro ecc.

I would like to have Unit Tests. How do I test the code that checks if the dispenser has money? Or that the cash is dispensed? Or that the account is debited when required? How can I mix unit tests with "BA Created" tests?

Allo stesso modo in TDD. Puoi scrivere le tue caratteristiche e i tuoi esempi in diversi framework (es. Cucumber e RSpec) o anche in linguaggi diversi (es. Scrivere esempi per un progetto C in C, e funzionalità in FIT / Fitnesse), puoi usare un singolo framework di caratteristiche per entrambi ( ad esempio scrivendo esempi e funzionalità in Cucumber) oppure è possibile utilizzare il framework di esempi singoli per entrambi (ad es. scrivere entrambi in RSpec). Non devi nemmeno usare un framework.

Un esempio di TDD-done-right (che è identico al BDD) usando solo un singolo framework è JUnit stesso, che contiene una combinazione di test unitari (esempi) e test funzionali / di integrazione (caratteristiche), tutti scritti in JUnit stesso.

Credo che Kent Beck chiami questo "zoom". Inizia ad alto livello, quindi "ingrandisci" i dettagli, quindi torna indietro.

Disclaimer: non sono un esperto di BDD, ma cerco di darti il mio punto di vista sull'articolo a cui ti sei collegato.

TDD è una tecnica di implementazione: prima scrivi un test, poi implementa il metodo, esegui il test, il refactoring e aggiungi ulteriori test per lo stesso metodo o per un nuovo metodo. TDD in realtà non definisce alcuna regola su come scegliere i nomi di classi o metodi, dipende da te. TDD inoltre non ti dice "quando hai finito".

Quindi ogni volta che scrivi un test per un nuovo metodo, devi scegliere un nome di metodo - e questo è il punto in cui entra in gioco BDD. Scegliendo i nomi dei metodi usando i termini di business dallo scenario sopra, e scegliendoli in un modo per descrivere il comportamento della tua classe, stai facendo BDD. Ogni volta che ti chiedi "devo aggiungere ulteriori test", puoi guardare gli scenari dati dal tuo BA e verificare se hai implementato completamente tutte le parti necessarie. In caso contrario, dovrai aggiungere altri test.

L'autore dell'articolo suggerisce anche di utilizzare uno schema di denominazione più legato al comportamento quando si scelgono i nomi dei test, ecco perché suggerisce di sostituire JUnit con uno strumento che non si basa su uno schema di denominazione in cui ogni caso di test ha per iniziare con il nome "test". Anche se non conosco JBehave, penso che questa sia la principale differenza tra quello strumento e Junit.

Inoltre, gli scenari BDD saranno anche un progetto per i test di integrazione, che tipicamente aggiungerai dopo che hai arricchito i nomi dei metodi da TDD e dopo aver aggiunto una quantità ragionevole di test unitari.

Quindi, per quanto ne so, TDD è uno strumento che puoi usare come parte di BDD, e BDD ti aiuta a scrivere i test giusti e dare loro nomi migliori.