Sono un po 'un sostenitore della metodologia Behavior Driven Development (aka BDD). Ho applicato BDD per un paio d'anni e ho adottato StoryQ come framework di scelta per lo sviluppo di applicazioni DotNet. Anche se sono stato test unitario per molti anni, e in precedenza avevo adottato un approccio test-first, ho scoperto che ottengo molto più valore dall'uso di un framework BDD, perché i miei test catturano l'intento dei requisiti relativamente chiaro l'inglese nel mio codice, e poiché i miei test possono eseguire più asserzioni senza terminare il test a metà strada - ciò significa che posso vedere quali asserzioni specifiche passano / falliscono a prima vista senza eseguire il debug per dimostrarlo.
Questa è stata davvero la punta dell'iceberg per me, poiché ho anche notato che sono in grado di eseguire il debug di entrambi i test e il codice di implementazione in modo più mirato, con il risultato che la mia produttività è cresciuta in modo significativo e che Riesco più facilmente a determinare dove si verifica un errore se si verifica un problema fino a raggiungere la build di integrazione a causa dell'output che si inserisce nei log di compilazione. Inoltre, la StoryQ api ha una bella sintassi fluente, facile da apprendere e che può essere applicata in un numero straordinario di modi, senza richiedere dipendenze esterne per poterla utilizzare.
Quindi con tutti questi vantaggi, si potrebbe pensare che sia facile introdurre il concetto al resto del team. Sfortunatamente, gli altri membri del team sono riluttanti a guardare StoryQ per valutarlo correttamente (per non parlare dell'idea di applicare BDD), e si sono convinti a provare a rimuovere un numero di elementi StoryQ dal nostro framework di testing core, anche sebbene originariamente supportassero l'uso di StoryQ e anche se il codice che desiderano rimuovere non ha alcun impatto su nessun'altra parte del nostro sistema di test. Fare così finirebbe per aumentare il mio carico di lavoro in modo significativo nel complesso e va davvero controcorrente, poiché sono convinto dall'esperienza pratica che è un modo migliore di lavorare in prima persona nel nostro particolare ambiente di lavoro, e può solo portare a maggiori miglioramenti nella qualità del nostro software, dato che ho trovato più facile rimanere con il primo test usando BDD. Per chiarire ulteriormente, la maggior parte dei test unitari tendono ad essere alquanto fragili e difficili da mantenere, un residuo di anni di test applicati male, in cui una riluttanza ad aderire a un processo guidato dai test ha visto gli sviluppatori ripiegare su vecchie abitudini e fai tutti i test alla fine del progetto (queste stesse persone sostengono di essere Agili!).
Quindi la domanda si riduce a quanto segue:
- Quali argomenti posso utilizzare per guidare veramente il punto a casa che sarebbe meglio per questo team usare StoryQ o almeno per adottare la metodologia BDD?
- Puoi indicarmi eventuali prove aneddotiche che posso utilizzare per supportare la mia argomentazione ad adottare BDD come metodo di scelta standard?
- Quali contro argomenti puoi pensare che potrebbe suggerire che il mio desiderio di incoraggiare la squadra ad adottare BDD potrebbe essere sbagliato? Sì, sono felice di essermi dimostrato sbagliato purché l'argomento sia valido.
NOTA : non sto sostenendo di riscrivere i nostri test nella loro interezza, ma piuttosto di iniziare semplicemente a lavorare in un modo diverso per tutti i futuri test di lavoro, e preferibilmente nel modo in cui ci impegniamo i nostri clienti.
E per quelli di voi che desiderano saperne di più su BDD, i seguenti link possono essere utili:
Per coloro che sono interessati a maggiori dettagli, siamo una piccola squadra di 4 persone che lavorano su circa 5 grandi progetti. Il "processo pilota" per BDD ha funzionato inizialmente per circa 2 mesi, con un altro periodo successivo di circa 4 mesi. La squadra ha accettato che avrei dovuto continuare a lavorare in questo modo e che dovevo fare le loro prove. Sono stato BDD-ing da circa 2 anni da quando il processo è terminato, mentre gli altri sono diventati molto bravi a ridurre il problema. Piuttosto che forzare uno "scontro" sul problema, sto cercando dei modi per convincere la squadra a smettere di giocare alle spalle collettive e trovare il tempo per fare la loro parte.