In che modo lo sviluppo guidato dal comportamento migliora la chiarezza quando le lingue naturali sono ambigue?

Hai ragione. Il BDD non elimina i problemi con l'ambiguità del linguaggio - non del tutto. Come altri hanno sottolineato, i frammenti tradotti devono essere abbinati definendoli correttamente, ma anche questo non risolve il problema di ambiguità sottostante.

Ora perché il BDD è davvero utile nonostante non risolva questo problema? Ci sono alcune ragioni e questa lista certamente non è completa.

L'ambiguità non è stata risolta

Questo non è né un motivo a favore di BDD né contro di esso. Ma quando lo si mette in contrasto con altri approcci come storie di utenti o requisiti, allora tutti gli approcci di sviluppo SW soffrono di ambiguità linguistiche poiché iniziano in un modo o nell'altro con una formulazione del linguaggio naturale.

Tecnicamente, il problema dell'ambiguità linguistica è stato risolto con linguaggi artificiali come lojban , ma poi ancora, i tuoi clienti e molto probabilmente gli sviluppatori non conosceranno quella lingua.

Lingua onnipresente

Il BDD va di pari passo con l'idea di un linguaggio onnipresente. Essere in grado di specificare gli scenari insieme a tutti i clienti, tester e sviluppatori, conferisce a BDD un vantaggio rispetto ad altri approcci.

Considera un tecnico dei requisiti tradizionale che annota tutti i requisiti. Una volta che tu, come tester o cliente, ottieni quel documento di 300 pagine pieno di requisiti da rivedere, avrai problemi molto più urgenti della terminologia utilizzata lì.

Le storie degli utenti fanno un po 'meglio su questo fronte, poiché includono anche tutte le parti interessate nella loro creazione. In termini di linguaggio ubiquo, non direi che sia BDD sia le storie degli utenti sono migliori, anche se differiscono significativamente nel punto successivo.

Testabilità

Un aspetto importante di BDD è che le tue specifiche sono effettivamente eseguibili (tramite Cucumber o simili). Né i requisiti né le storie degli utenti offrono questa funzionalità. Per me personalmente, questo è il principale argomento di vendita per BDD.

Contrariamente a ciò con i requisiti tradizionali - abbiamo detto ai tecnici dei requisiti da anni che i loro requisiti dovrebbero essere verificabili. Tuttavia, ogni progetto vede un caso in cui da qualche parte i tester si rendono conto che non hanno idea di come testare un determinato requisito.

Le storie degli utenti, se fatte bene, includono i tester nella loro fase iniziale di creazione per accertarsi di ciò. Sfortunatamente, questo è un caso di teoria che si scontra con il mondo reale, dove ho visto numerose storie che nessun tester ha mai visto prima.

BDD d'altra parte offre automaticamente uno scenario di test eseguibile. Non ci sono scuse e non c'è alcun modo per aggirare questo (beh, a meno che non ignori completamente i livelli di automazione e scriva solo gli scenari per la poesia di fantasia).

Più in generale, Test First è un principio che è stato molto gratificante in tutte le fasi dello sviluppo del software e BDD è la sua applicazione al livello più esterno dello sviluppo (rispetto al TDD f.ex. a livello di unità).

Sommario

In sintesi, BDD non ti eleva dai problemi dell'ambiguità del linguaggio naturale. Tuttavia, ti aiuta ad affrontare questo problema attraverso due punti importanti: Concentrarsi su un linguaggio ubiquo per ridurre le ambiguità (non lo eliminerà del tutto, ma aiuta un sacco!) E costringendoti a scrivere un eseguibile specifiche. Quest'ultimo punto aiuta a risolvere i problemi di ambiguità, soprattutto perché questo è il punto in cui le ambiguità iniziano a presentarsi come problemi altrimenti.

Quando qualcosa è scritto in "linguaggio naturale" ciò può significare un numero di cose:

• Questo è letteralmente inglese. Poiché l'inglese è un linguaggio molto ambiguo e impreciso, questa modalità di inserimento non è soddisfacente nel contesto dello sviluppo del software.

• Questo è l'inglese, ma i termini pertinenti sono definiti con precisione. Tale linguaggio è usato in documenti legali, o testi matematici.

• Questo è un linguaggio formale, ma il linguaggio è modellato molto attentamente dopo le convenzioni del linguaggio naturale. Questo descrive tutti i linguaggi di programmazione, in una certa misura. Più il linguaggio formale è simile all'inglese, più è facile da capire per i lettori non addestrati. Esempi significativi di linguaggi di programmazione con questo obiettivo includono COBOL e SQL: select id, name from persons where age > 18 è immediatamente evidente. Lo svantaggio di questi linguaggi è che è necessario comprendere il linguaggio formale per scrivere codice di lavoro. Inoltre, queste lingue sono spesso molto prolisse.

DDD suggerisce che il progetto utilizza un linguaggio ubiquitario per descrivere il dominio. Questo è essenzialmente il caso 2: definisci termini rilevanti in modo che tu possa comunicare con precisione all'interno del linguaggio naturale.

Cetriolo stesso è il caso 3: un linguaggio formale che ha l'intenzione di leggere molto vicino al normale inglese. Più precisamente: Cucumber è un framework che consente di definire un linguaggio formale semplice che può essere utilizzato per esprimere requisiti / test. Il punto qui è che lo stesso documento rappresenta i requisiti del linguaggio naturale e test eseguibili automaticamente, quindi i due saranno sempre sincronizzati. Puoi leggere uno scenario di cetriolo e verificare che esprima correttamente la tua esigenza senza dover capire come funziona tutto questo.

Cucumber funziona abbinando il documento a snippet conosciuti di linguaggio naturale. Questi snippet devono essere definiti per primi. Per scrivere uno scenario in Cucumber, è necessario essere a conoscenza dei frammenti disponibili: il software non leggerà la tua mente. Questi snippet sono anche una fonte di possibili problemi: quando implementi il comportamento di uno snippet di testo, il tuo codice potrebbe fare qualcosa di leggermente diverso dal suggerimento del testo frammento. È improbabile che questo sia un problema se lo stesso frammento viene utilizzato molte volte. Cucumber è quindi adatto per descrivere le regole aziendali che consistono in un insieme più limitato di condizioni, azioni e risultati. Altri framework di test potrebbero essere migliori se ogni frammento fosse utilizzato una o due volte, ad es. perché l'impostazione per ogni caso di test è unica.

@ Raghuram8892, il testo dopo le parole chiave Given / When / Then / And deve corrispondere allo "snippet", altrimenti il passo fallisce come indefinito o "in sospeso". In quanto tale, rientra esattamente nel caso 3.

Riguardo "Inglese", Cucumber e la sua lingua, Gherkin sono progettati per uso internazionale. Puoi richiamare il comando, cucumber --i18n help per visualizzare l'elenco delle lingue attualmente supportate e cucumber --i18n $CODE per visualizzare le parole chiave per un particolare codice lingua. Ad esempio, cucumber --i18n eo fornisce le parole chiave per Esperanto.