Ho riscontrato un problema nella visualizzazione di come il gap viene chiuso tra test a grana grossa, boundary n-tier, test di accettazione automatizzati di alto livello e testing di livello inferiore, task / sotto-task.
La mia motivazione è di essere in grado di eseguire qualsiasi test unitario nel mio sistema ed essere in grado di seguire all'indietro, attraverso la copertura, quali scenari utilizzare per quel test unitario.
Ho familiarità con le idee di BDD : un'estensione di TDD e gli scenari di scrittura al livello di progettazione di soluzioni di alto livello nel formato Gerkin , e guidando questi scenari usando strumenti come JBehave e% % co_de.
Allo stesso modo, ho familiarità con l'umile unit test a livello di utility o task e usando Cucumber per testare i vari percorsi della funzione.
Quando comincio a scollarmi, è quando cerco di immaginare queste due discipline applicate insieme in un contesto aziendale.
Forse sto sbagliando perché tendi ad usare un approccio o l'altro?
Nel tentativo di articolare i miei pensieri fino ad ora, affermiamo che ho ragione di credere che entrambi siano usati.
In un xUnit world, agile sono scomposti in user stories e tasks , e in un'impostazione aziendale, dove i problemi sono grandi e il numero di sviluppatori per sub-tasks sono molti, quelle attività e sotto-compiti sono distribuiti tra un gruppo di persone con competenze specialistiche di risoluzione dei problemi.
Alcuni sviluppatori, ad esempio, potrebbero specializzarsi nello sviluppo di medio livello, sviluppare un layer story e continuare a lavorare verso il basso. Altri possono specializzarsi nello sviluppo dell'interfaccia utente e lavorare da un livello controller verso l'alto.
Gli sviluppatori possono quindi condividere l'implementazione di una singola stringa di compiti che, una volta incollati di nuovo insieme, implementeranno il controller .
In questo caso, mi sembra che siano ancora necessari cicli di story a livello di attività e sotto-attività, per garantire che gli sforzi di questi sviluppatori collaborino correttamente all'interno di un livello e da uno strato a quello successivo ( simpatizzanti collaboratori).
Lavorare in questo modo implica una certa quantità di progettazione di soluzioni di alto livello in anticipo, quindi i contratti tra gli strati sono concordati e rispettati. Forse questo è articolato come TDD e forse questo emerge durante la sessione di ripartizione sequence diagram per task .
Tuttavia, d'altra parte, abbiamo il valore di definire i test di accettazione story a un livello superiore per configurare che tutti i blocchi funzionino insieme come previsto - una forma di super-integrazione test, suppongo.
Suppongo che la risposta che sto cercando qui, a parte il più semplice sì / no alla domanda di "entrambi", sia una spiegazione / un esempio funzionante di come io e un gruppo di sviluppatori iniziamo con un singolo n-tier scenario e finiscono con un'implementazione in un ambiente aziendale, dove siamo stati in grado di suddividere le attività in livelli e condividerle tra di noi e lavorare in parallelo per trasformare il test dello scenario BDD da rosso a verde, per tutto il tempo assicurandoci che il codice che scriviamo sia scritto solo perché lo scenario lo richiede, ea un livello a grana fine il codice che abbiamo scritto è appropriatamente testato unitamente a cicli di BDD a livello di task e sotto-task.
Se, naturalmente, è corretto ?
