In che modo lo sviluppo guidato dal comportamento migliora la chiarezza quando i linguaggi naturali sono ambigui?

Attualmente sto esplorando framework di test BDD come il cetriolo e lo trovo curioso quando la gente dice

poiché i file delle caratteristiche sono in un semplice linguaggio naturale, migliora la chiarezza e offre una visione chiara

ma, il linguaggio naturale non è la causa della maggior parte dei problemi che abbiamo nell'ingegneria del software?

Il linguaggio naturale è ambiguo ed è la ragione per cui molti progetti software falliscono a causa dell'errata interpretazione dei requisiti dei clienti e della comprensione dello sviluppatore. Non capisco la nicchia qui.

Sì, suddividere i test in minuscole azioni semplici ha senso e dà un certo livello di chiarezza, ma migliora la produttività nel suo complesso?

PS: Non sono un esperto e non sto facendo un'opinione qui. Sono solo curioso di capire il concetto.

Hai ragione. BDD non elimina i problemi con l'ambiguità del linguaggio - per niente. Come altri hanno sottolineato, gli snippet che vengono tradotti devono essere abbinati definendoli correttamente, ma anche questo non affronta il problema di ambiguità sottostante.

Ora, perché BDD vale davvero la pena nonostante non si risolva questo problema? Ci sono alcuni motivi e questo elenco certamente non è completo.

L'ambiguità non è stata risolta

Questo non è né un motivo a favore di BDD né contro di esso. Ma quando lo contrapponi ad altri approcci come le storie o i requisiti degli utenti, allora tutti gli approcci di sviluppo SW soffrono di ambiguità del linguaggio poiché iniziano tutti 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 molto probabilmente i vostri clienti e sviluppatori probabilmente non conosceranno quella lingua.

Linguaggio ubiquitario

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

Considera un ingegnere di requisiti tradizionale che annota tutti i requisiti. Una volta che sei un tester o un cliente che ottieni quel documento di 300 pagine pieno di requisiti da rivedere, avrai molti più problemi pressanti rispetto alla terminologia che è stata usata 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 onnipresente, non direi che BDD o le storie degli utenti siano 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 funzione. Personalmente, questo è il principale punto di forza per BDD.

In contrasto con i requisiti tradizionali: da anni diciamo agli ingegneri dei requisiti che i loro requisiti dovrebbero essere verificabili. Tuttavia, ogni progetto vede un caso in cui da qualche parte i tester della linea si rendono conto di non avere idea di come testare un determinato requisito.

Le storie degli utenti, se eseguite correttamente, includono i tester nella fase iniziale di creazione per accertarsene. Sfortunatamente, questo è un caso di teoria che si scontra con il mondo reale, in cui ho visto numerose storie che nessun tester ha mai visto prima.

BDD d'altra parte ti dà automaticamente uno scenario di test eseguibile. Non ci sono scuse e modi per evitarlo (beh, a meno che non si ignori completamente i livelli di automazione e si scrivano solo scenari per la poesia elaborata).

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

Sommario

In sintesi, BDD non ti solleva dai problemi di ambiguità del linguaggio naturale. Ti aiuta, tuttavia, ad affrontare questo problema attraverso due punti importanti: Concentrarsi su un linguaggio onnipresente per ridurre le ambiguità (non le eliminerà del tutto, ma aiuta un sacco!) E costringendoti a scrivere eseguibile specifiche. Quest'ultimo punto sta aiutando ad affrontare i problemi di ambiguità principalmente perché quello è il punto in cui le ambiguità iniziano a manifestarsi come problemi altrimenti.

Quando qualcosa è scritto in "linguaggio naturale" questo può significare una serie di cose:

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

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

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

DDD suggerisce che il progetto utilizza un linguaggio onnipresente per descrivere il dominio. Questo è essenzialmente il caso 2: definire termini pertinenti in modo da poter comunicare con precisione all'interno del linguaggio naturale.

Il 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 i test eseguibili automaticamente, quindi i due saranno sempre sincronizzati. Puoi leggere uno scenario di cetriolo e verificare che esprima correttamente il tuo requisito senza dover capire come funziona tutto questo.

Il cetriolo funziona abbinando il documento a frammenti noti di linguaggio naturale. Questi frammenti devono essere definiti per primi. Per scrivere uno scenario in Cetriolo, devi essere consapevole degli snippet disponibili: il software non ti leggerà. Questi frammenti sono anche una fonte di possibili problemi: quando si implementa il comportamento di uno snippet di testo, il codice potrebbe fare qualcosa di leggermente diverso da quello suggerito dal testo dello snippet. È improbabile che ciò sia un problema se lo stesso frammento viene utilizzato più volte. Il cetriolo è quindi adatto per descrivere le regole aziendali che consistono in un insieme più piccolo di condizioni, azioni e risultati. Altri framework di test potrebbero essere migliori se ogni frammento dovesse essere utilizzato solo una o due volte, ad esempio perché l'impostazione per ciascun caso di test è unica.

@ Raghuram8892, il testo dopo le parole chiave Dato / Quando / Allora / E deve corrispondere allo "snippet", altrimenti il ​​passaggio fallisce come indefinito o "in sospeso". Come tale, rientra perfettamente nel caso 3.

Per quanto riguarda "l'inglese", il cetriolo e la sua lingua, i cetriolini sono progettati per un uso internazionale. È possibile richiamare il comando, cucumber --i18n helpper visualizzare l'elenco delle lingue attualmente supportate e cucumber --i18n $CODEper visualizzare le parole chiave per un determinato codice lingua. Ad esempio, cucumber --i18n eofornisce le parole chiave per l'esperanto.