Dovrebbe essere usato uno stile imperativo se i parametri determinano il risultato?

Normalmente quando le persone parlano di dichiarativo contro imperativo, è fatto per evitare elementi troppo dettagliati in scenari che diventerebbero difficili da mantenere.

Quindi, ad esempio, questo sarebbe sicuramente definito "imperativo":

Given Fred bought a microwave costing £100
And we scanned a 10% discount card
And we scanned his card with number XXXX XXXX XXXX 1234
And we clicked to pay the whole balance with that card
When we scan the receipt  
And click the button "refund"
And click "refund to original card"
Then the card XXXX XXXX XXXX 1234 should get £100 back.

Puoi vedere che c'è una quantità enorme di dettagli lì! Anche se lo facessimo senza il clic dei pulsanti o qualsiasi altro riferimento all'interfaccia utente, sarebbe comunque troppo dettagliato:

Given Fred bought a microwave costing £100
And used a 10% discount card
And he paid with credit card XXXX XXXX XXXX 1234
....

Questo non è proprio il modo in cui qualcuno parlerebbe di questo scenario. A nessuno importa se lo sconto fosse una carta sconto o uno sconto dato dal manager; non importa. A nessuno importa quale fosse il numero sulla carta. Ecco lo scenario a cui stanno a cuore:

Given Fred bought a microwave for £100 with a 10% discount
When he asks for a refund
Then £90 should be refunded to the original card.

È facile da leggere e ricordare e parlare, e ha abbastanza dettagli in esso per essere in grado di vedere cosa sta succedendo. Qualsiasi passo più fine può essere chiamato da questi più grandi.

Si noti che questo esempio è ancora specifico , il che significa che è ancora possibile essere parametrizzato. Non dice:

Given a customer bought an item with a discount
When the customer asks for a refund
Then the cost minus the discount should be refunded to the original card.

Questo non è in realtà uno scenario; questo è un criterio di accettazione in forma di scenario. È astratto piuttosto che specifico .

Specifico contro astratto è ortogonale a dichiarativo vs imperativo. Vuoi che sia dichiarativo , ma specifico .

La tua prima serie di scenari va bene da quella prospettiva. Il tuo secondo set è troppo astratto e non abbastanza specifico. Entrambi mi sembrano dichiarativi.

Per ulteriori informazioni e suggerimenti su come farlo, vedi gli articoli originali di Dan North su questo; "Cosa c'è in una storia?" e " Di chi è il dominio in ogni caso? "

Per rispondere alla tua domanda, devi chiedere a chi si aspetta di vedere i risultati del test. Lo usiamo come una forma di test di accettazione. BDD ha lo scopo di fornire un ponte tra ciò che chiede il cliente e ciò che i programmatori devono soddisfare. Preso la semplice affermazione:

Given a Person
When I calculate eligibility for insurance
Then the result should be insurance that the person is eligible for

La lingua è molto concisa e chiara. Questo è qualcosa che il tuo cliente può leggere e capire, e quando vedono un segno di passaggio per quella dichiarazione sanno cosa significa. Funziona anche per limitare il creep dello scope, dal momento che il client non sta inventando nuovi casi che non esistevano prima.

La forma imperativa si legge come pensa un programmatore. Questo è molto diverso da come pensa un uomo d'affari. Essenzialmente stai scrivendo la tua domanda 2 volte. Una volta in una struttura simile a BDD e una volta nel codice. Questo non aiuta nessuno. È noioso da leggere, noioso da scrivere e confondere il tuo cliente. Lo scenario peggiore è che scrivi il tuo BDD imperativo in modo così restrittivo da non poter cambiare la struttura del tuo codice perché i tuoi test BDD sono troppo strettamente accoppiati. Non farlo.

Come programmatore, devi definire nel codice che mappa l'istruzione BDD insurance that the person is eligible for . Considerata la combinazione di prodotto assicurativo e persona, è possibile eseguire lo stesso test per determinare se l'associazione è valida o no. Applicarlo a un insieme di prodotti per assicurarsi che tutti i prodotti restituiti siano validi per una persona è banale. In effetti, probabilmente hai già definito questa funzione nel tuo codice sorgente.

Il punto che l'articolo sta facendo riguarda l'idea che le storie degli utenti debbano occuparsi di ciò che è la funzionalità, non di come dovrebbe essere implementata. Quindi una storia che parla in termini di "e i clic dell'utente entrano" ecc. È una brutta storia. È troppo prescrittivo. Dovrebbe essere più dichiarativo, come per gli esempi in quell'articolo, quindi si concentra su ciò che è necessario, non su come deve essere implementato.

Quindi nel tuo caso, se la tua storia dovesse parlare di un uomo con più di 21 anni ammissibile per determinati prodotti, tutto dipende da dove tali regole commerciali sono definite. Se sono hard-coded nell'app con la comprensione che se le regole cambiano, l'app cambia, quindi fanno parte dei requisiti e dovrebbero quindi far parte di quel test. Quindi entrano nella storia e sono specificamente testati per.

Se, tuttavia, le regole sono configurabili tramite ad esempio il database, non dovrebbero assolutamente far parte dei requisiti. In tal caso, quindi la storia dovrebbe effettivamente parlare in termini di "Quindi il risultato dovrebbe essere l'assicurazione che la persona è ammissibile per".