Test Driven vs. Behavior Driven

Ciao Gianni, spero che con la tua immensa sapienza tu riesca a darmi una risposta alla domanda che mi ronza in testa da un pò di tempo. ::)

Avvicinandomi al mondo dell'eXtreme Programming sono entrato a contatto con tecniche quali il tdd (Test Driven Development) e il bdd (Behavior Driven Development) credo di aver ben chiara la differenza tra i due, il problema è:

come mai - nonostante il bdd sembri il passo successivo dell'evoluzione del tdd - se l'obiettivo di una test suite è quello di specificare il comportamento del programma, e il bdd lo fa già, non si usa il bdd anziché il tdd?

Una piccola parentesi, riguardo la strana sensazione di isolamento che c'è durante la stesura degli unitTests-

Da un certo punto di vista apprezzo questa cosa, dall'altro mi lascia confuso, perchè vedendo uno di quei talk di Google il relatore (Dave Astels) diceva che l'isolamento è uno dei difetti delle unità di test, da questo ho dedotto che il bdd, in qualche modo, vada "applicato" direttamente nel codice dell'applicazione.

Questi dubbi mi ostacolano in quanto non sono ancora convinto da dove partire, dal tdd (per poi arrivare al bdd, quando avrò conosciuto i limiti (?) del tdd) o direttamente dal bdd?

:bye:

Mi piacerebbe conoscere il parere di qualche filo-tdd riguardo il bdd, visto che ho fatto già il contrario :P, giusto per essere neutrale e decidere meglio.

Pensavo di chiedere a Bergmann - il creatore di phpUnit - magari ne esce pure un bell'articolo?

inviato 8 anni fa
Andrea Turso
Andrea Turso
86
modificato 8 anni fa
X 0 X

In azienda usiamo un approccio tendente al "Behavior Driven Development", anche perché forse è più adatto alla metodologia RUP.

Inoltre gli sviluppatori conoscono bene il "dominio" su cui sviluppano le applicazioni, quindi si preferisce lavorare su casi di test reali piuttosto che sul test del singolo modulo software. Inoltre sono test facili da documentare e che il committente può verificare personalmente.

Questi test infine permettono una verifica dell'integrazione delle varie componenti realizzate da diversi sviluppatori.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Ciao Gianni, grazie per la risposta, concedimi qualche altra domanda:

I test sono creati in suites a parte o fanno parte del codice sorgente dell'applicazione?

Potresti farmi un esempio dell'approccio utilizzato da voi in azienda?

Quindi secondo te dovrei orientarmi verso il "Behavior Driven Development"?

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

I casi di test sono formalizzati da persone in carne e ossa, quasi sempre sono analisti con una profonda conoscenza del dominio applicativo. Il test viene descritto indicando l'interazione tra l'utente ed il sistema (front-end), indicando con precisione i dati inseriti dall'utente e tutte le precondizioni che devono essere verificate. Infine vendono descritti i risultati attesi.

La verifica dei test viene eseguita da persone in carne e ossa che eseguono il test come descritto e indicano se l'esito è quello atteso.

Solo per alcune procedure vengono realizzati test unitari.

Credo che la scelta sulla tipologia di test da effettuare dipenda dal tipo di software che si scrive

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X

Praticamente ci sono i tester (umani) che "giocano" con l'applicazione durante il suo sviluppo e provvedono a fornire feedback direttamente.

Lol, Human Driven Development ?  :P

So già che mi toccherà chiedere a Bergmann per togliermi questo maledettissimo dubbio ^^

Perchè i test fuori dall'applicazione?

(ipotetica risposta) Perchè altrimenti dovrai aggiungere il framework di testing alle dipendenze della tua applicazione

Quindi isoliamo i test.

I test sono isolati, che brutta sensazione...

Poi escono i filo-bdd e dicono che è un male avere i test isolati, allora intregriamoli!

Ma così saremo costretti ad aggiungere il framework di testing alle dipendenze dell'applicazione!

[ si ripete ]

:2funny:

Aiuto...

L'unico problema dei tester umani è che non puoi fargli eseguire le test suite per una nightly build di una patch alle 3 di notte ;D e comunque fargli eseguire 200 macchinosi test è da suicidio -.-

:bye:

risposto 8 anni fa
Andrea Turso
Andrea Turso
86
modificato 8 anni fa
X 0 X

Come ti dicevo, la tipologia di test da realizzare dipende dalla tipologia di software che si sta testando.

Se una singola entità software si conporta (più o meno) sempre allo stesso modo, indipendentemente dai parametri passati, allora i test unitari sono l'ideale.

Rimane da testare il sistema al momento dell'integrazione delle parti, ma questa attività potrebbe avere una minore importanza se la complessità del sistema non è nell'interazione delle sue parti ma all'interno delle singole parti.

Se invece una singola entità software può avere mutevoli comportamenti in funzione dei dati passati e di quelli che trova sul database, scrivere test unitari diventa più difficile dello scrivere l'applicazione vera e propria. Se l'intera applicazione puoi fa interagire numerose componenti di questo tipo per gerare il risultato finale (una transazione) allora puoi immaginare come lo sforzo nel creare i test unitari comunque non porterebbe alla verifica del buon funzionamento dell'applicazione.

Anche se sembra brutto dirlo appertamente, i nostri migliori tester sono i nostri clienti, che affrontano giorno dopo giorno le situazioni più disparate.

 :bye:

risposto 8 anni fa
Gianni Tomasicchio
X 0 X
Effettua l'accesso o registrati per rispondere a questa domanda