Secondo passo di BDD - scrivi "failing scenario step", significa test?

Question

Secondo passo di BDD - scrivi "failing scenario step", significa test?

#1 da (1 voti)

2

Sapendo che il BDD in qualche modo evita di usare il termine "test", sto cercando di capire il processo come descritto in un libro intitolato The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy.

Descrivono il processo BDD in questo modo:

Seleziona uno scenario da una funzione
Scrivi un passaggio di scenario in errore
Scrivi un test in errore per supportare il comportamento dettagliato nei passaggi non riusciti
Scrivi il codice per eseguire il test del test dell'unità
Refactor
Se il passaggio viene superato, passa al passaggio successivo, altrimenti scopri altri oggetti per supportare il comportamento dettagliato fino al passaggio del passaggio.

"Given", "When", "Then" sono considerati i passaggi.
Lo scenario di esempio era "Dato che sono su una pagina dei dettagli del prodotto .."

Sotto il diagramma, spiegano: ...

The next action is to create a failing scenario step. In this instance, you would create code that confirms that the product page can be displayed.

Non capisco. Qual è il passaggio dello scenario di errore, se non un test (e non sembra essere il test come quelli sono menzionati nel passaggio 4)? Se non è il test (ma qualsiasi altro codice), non sto infrangendo la regola TDD (test prima)?

Il link al libro e al testo originale: link

tdd bdd design development-process

posta John V 24.05.2018 - 15:46

fonte

1 risposta

Leggi altre domande sui tag tdd bdd design development-process

Implementazione di un'API REST in un'architettura pulita Dove memorizzare le impostazioni di configurazione in un file di testo e quando si trova in un database?

score 1 · Answer 1

Uno scenario è solo un testo leggibile. In questo caso, scrivere un passaggio di scenario in errore significa tradurre i pezzi dello scenario in codice di test eseguibile, in modo da poter verificare automaticamente se lo scenario è stato implementato.

Questo è particolarmente chiaro se si utilizza Cucumber per scrivere lo scenario. Il test runner di Cucumber analizzerà lo scenario ma contrassegnerà ogni passaggio come non implementato. Dovrai quindi prima scrivere il codice necessario per analizzare ed eseguire quel passaggio, cioè trasformare lo scenario in un test. Alcuni o tutti questi passaggi potrebbero non riuscire inizialmente. In uno scenario di stile dato / quando / poi, almeno il passaggio "allora" dovrebbe fallire. Mentre scrivi il passo, potresti anche riformulare lo scenario per renderlo più chiaro e più facile da analizzare.

Ora hai uno scenario testabile automaticamente con passaggi falliti. Successivamente, si selezionerebbe un passaggio e si passerà al ciclo TDD in cui si scrivono i test unitari e si scrive il codice fino a che tale passaggio non inizia a passare. Una volta fatto ciò, si torna indietro nel ciclo BDD e si prosegue con il prossimo passaggio non riuscito o non implementato o con il prossimo scenario.

Sì, gli scenari sono certamente una sorta di test quando vengono trattati in questo modo. Ma essere automaticamente testabili è solo una preoccupazione secondaria, e gli scenari riguardano principalmente una comunicazione chiara tra clienti o esperti di dominio e sviluppatori. I test / gli scenari in stile BDD sono in genere di alto livello, orientati all'utente, end-to-end e incentrati sulle regole aziendali. Al contrario, test unitari incl. I test in stile TDD sono più granulari, coprono componenti più piccoli e sono più interessati alle interfacce del codice in prova.