Interessanti domande sullo sviluppo comportamentale

BDD è in realtà TDD con terminologia fissa (vedi qui ).

wiki BDD fornisce una spiegazione chiara. Se fatto bene, può funzionare abbastanza bene. Almeno ha funzionato molto bene nella mia squadra quando siamo passati dalla codifica quasi da cowboy. La copertura del codice è aumentata e, con essa, il numero di bug è stato ridotto e la qualità è aumentata.

Ciò che è anche positivo è che ottieni automaticamente YAGNI , KISS e se fatto bene SOLID .

how the output of a new development technique like BDD can be validated?

Come altri metodi di sviluppo, BDD non è un proiettile d'argento (cosa del genere ancora non esiste nello sviluppo del software). Se dopo qualche tempo non vedi miglioramenti nella qualità del codice, allora è meglio non usarlo. Sotto la qualità del codice, intendo: meno bug, più facile implementare le richieste di modifica, ecc.

Penso che sarebbe un contributo molto valido per convalidare / testare la premessa che BDD porti a una suite di test più snella, più orientata all'utente.

I codebase diventano molto difficili da evolvere nel tempo, in parte perché è difficile differenziare la complessità accidentale dalle eccezioni guidate dal dominio. Cioè, quando si guarda un pezzo di codice che sembra come potrebbe essere rifattorizzato per essere più semplice, si deve considerare la possibilità molto reale che la complessità derivi da qualche regola del dominio. ("Possiamo refactoring foo->bar->bat->baz per eliminare bar o bat ?" "Accidenti, dobbiamo avere bar e bat per qualche ragione!")

In una codebase moderna, ci aspettiamo che tutta questa complessità sia esercitata dal codice di test. Nel momento in cui eliminiamo bar o bat ci aspettiamo che la suite si interrompa, non solo bar e bat , ma anche foo , poiché dipende. La premessa di BDD è che hai cornici significative per l'utente che mostrano che bar è basso valore utente, bat è associato a più valore e foo è molto alto, quindi, teoricamente, dovresti essere in grado di dì "Beh, abbiamo avere per ripristinare ogni foo test su green, dobbiamo recuperare questi bat di comportamenti, ma possiamo perdere bar interamente."

Ma è davvero così che funziona? Oppure le suite di test BDD si trasformano in una sottile copertina di "Come utente di foo mi aspetto che bar sia valido?" (testare l'implementazione piuttosto che il comportamento prezioso dell'utente)?

Sarà difficile fare analisi statistiche sulla differenza tra due metodologie di sviluppo. È probabilmente oltre lo scopo di un dottorato e tanto meno una tesi di master.

Una cosa che potrebbe essere interessante è un'immersione profonda su un risultato specifico. Ad esempio, in che modo la stima (o il piano di test) differisce tra di loro? Se lo mantieni gestibile, potresti trovare un modo per convincere il tuo capo a fare un piccolo passo avanti.

Per prima cosa comprendi che lo sviluppo comportamentale (BDD) non equivale alle specifiche eseguibili nella lingua del cliente.

Lo sviluppo guidato dal comportamento è uguale allo sviluppo basato su test (TDD) in linguaggio comportamentale.

TDD / BDD può portare grandi benefici alla progettazione, alla qualità del codice e così via, se fatto in modo pragmatico dagli sviluppatori esperti di BDD.

I requisiti eseguibili possono anche portare benefici, ma ciò dipende più dal rapporto con il cliente, dalla natura del prodotto e dall'organizzazione.

> (...) have you ever felt something about BDD that you would want to 
> investigate in (...) ? 
> This could help me a lot with constructing my research question. 

Quando usig dotnet-specflow l'ho trovato difficile da tenere traccia delle definizioni di passi / azioni-metodo riutilizzabili e frammenti di testo corrispondenti. Per me è come avere software con molte variabili e metodi globali.

La tua ricerca può farcela con l'organizzazione di questi?