Come gestiamo le permutazioni minori degli scenari BDD?

Question

Mi piace l'approccio BDD allo sviluppo, ma mi sono imbattuto in una preoccupazione per quanto lontano andare. Questo commento da ThoughtWorks più recente Radar mi dà una pausa:

"L'avvento del design comportamento-driven (BDD) framework di test come il cetriolo, in combinazione con strumenti di automazione del browser come il selenio, ha incoraggiato l'uso diffuso di test di accettazione presso il livello di browser, che purtroppo è stato incoraggiato a eseguire la maggior parte dei test in cui il costo per eseguire i test è il massimo, ma dovremmo testare al livello appropriato, il più vicino possibile al codice, in modo che i test possano essere eseguiti con la massima efficienza. I test a livello di browser dovrebbero essere la ciliegina sulla torta, supportati da test di accettazione e unitari eseguiti a livelli appropriati. "

Quindi, ecco il mio scenario (gioco di parole):

Ho un app di base CRUD con un requisito aziendale per filtrare i dati visualizzati basano su criteri l'utente finale è autorizzato a selezionare. Per facilità di discussione, diciamo che è un'app per la compagnia elettrica e sto visualizzando l'attuale consumo di energia di ogni mese per ciascun cliente. L'utente di questa app potrebbe restringere i dati selezionando un singolo cliente, più clienti, nessun cliente o "Tutti i clienti". I dati visualizzati cambieranno in base a ciò che selezionano.

Per uno stakeholder del prodotto, questi davvero rappresentano 4 scenari separati. Tuttavia dal punto di vista dello sviluppatore sono praticamente identici, con l'unica differenza che è un parametro passato al DB. Quindi la domanda diventa: il vantaggio di avere ciascuna permutazione enunciata supera il costo della gestione e della manutenzione?

Penso principi BDD probabilmente dire "sì", perché la comunicazione del comportamento atteso è più esplicito, ma non sono sicuro. Certamente mi ha dato la sensazione di essere eccessivo. Gli scenari potrebbero essere un sacco di copia-incolla con piccole modifiche.

La mia inclinazione è quella di coprire questa funzionalità con un singolo scenario che cattura il valore del core business ("quando seleziono un cliente vedo i dati di utilizzo di energia"), e quindi coprire le altre permutazioni con un set di non-UI I test di integrazione basati sulla convalida del servizio/query restituiscono i dati corretti. Questo pensiero è sbagliato? Qual è la migliore risposta per assicurarti che questi scenari siano coperti, senza rinunciare ai benefici di BDD?

Answer 1

La mia regola per BDD è che gli sviluppatori dovrebbero facilmente essere in grado di ricavare gli scenari da qualsiasi comportamento sia descritto, e se non possono, illustrare il comportamento con gli scenari.

BDD è al suo più utile quando è descrivere le cose che sono difficili; o quando si passa la conoscenza di esperti agli sviluppatori o si restringe il comportamento fino a quando non si scopre l'incertezza. In un'applicazione CRUD con filtri di base, il comportamento è davvero facile da capire.

Quello che stai descrivendo è probabilmente il migliore schema di Dan North "Ginger Cake": prendi la ricetta per qualcos'altro, ma con un aspetto del comportamento diverso da un altro (o in questo caso con un altro, facile da capire l'aspetto del comportamento). Usa anche copia-incolla un po ', e sospetto in particolare per questo tipo di comportamento.

Così, la vostra inclinazione è perfettamente corretto. Se automatizzando, probabilmente automatizzerei solo un esempio e lasciare che i test di unità e integrazione coprano il resto.

mi piacerebbe anche sapere il motivo per cui questo progetto è stato perseguito. Ci deve essere qualcosa di interessante, o non sarebbe successo.Trovalo e probabilmente è un ottimo punto di partenza per discutere degli scenari.

Answer 2

Se si stanno rielaborando gli scenari, in genere estraendo piccole tabelle da script duplicati, i costi di manutenzione probabilmente non vi faranno del male. Questo però non risolve il problema del costo del tempo di esecuzione.

In tale situazione, probabilmente suggerirei di automatizzare sia lo scenario più semplice (senza clienti) che il più complicato (molti clienti corrispondono a un filtro, ma non tutti) e lasciano le altre permutazioni a test di programmatori più mirati. Includerei il caso "nessun cliente" solo perché le persone hanno la tendenza a sbagliare in modo orribile, come nel caso in cui il programma si blocca di tanto in tanto. (Non hai eseguito lo script dei dati seme ?!)