Come scrivere storie di utenti per un solo test di accettazione?

Esiste chiaramente un dilemma tra "storie utente espresse dal cliente" e "prove abbastanza piccole da dirti cosa è rotto"

Una user story è pensata per essere proprio questo, non una ripartizione di tutti i casi limite. Se provi a renderli così piccoli, ti mancherai un po 'e il cliente perderà la connessione e dirà "ma non è quello che ho chiesto!"

Un test di grandi dimensioni, "l'accesso dell'utente" potrebbe essere utile per il controllo dell'accettazione e l'approvazione / superamento della storia. Ma non coprirà importanti casi limite che dovresti testare.

Non penso che dovresti provare a risolvere questo problema. Basta tenere la storia in grande e scrivere più test.

Questo tizio sta chiaramente inseguendo l'ultimo clamore piuttosto che preoccuparsi di aspetti pratici.

BDD presenta un approccio che potrebbe essere utile: una user story è arricchita da scenari / esempi. Questi scenari sono sia una specifica leggibile dall'uomo sia test di comportamento eseguibili. Ogni scenario è quindi abbastanza piccolo da poter essere contato.

Ci sarà ancora una notevole variabilità per lo sforzo tra gli scenari, ma confezionandoli in piccoli scenari non ambigui si riduce il rischio di variabilità inaspettata.

TBH Penso che la variabilità tra gli scenari sarà ancora così grande che non è pratico contarli semplicemente. In particolare, i primi scenari di una storia vedranno un maggiore sforzo per l'infrastruttura da cui trarranno vantaggio gli scenari successivi.

Va anche notato che rompendo una storia di un utente in piccoli scenari testabili, stiamo caricando molto del carico frontale. Questo è discutibilmente buono, nel senso di fallire velocemente. Ma abbattere le storie è anche un grande sforzo per implementare una storia. Questo fa sorgere la meta-domanda: quale storia vale la pena abbattere dopo? Quanto sforzo vorrebbe abbattere questa storia o quella storia? Stimare quella preparazione è ovviamente più semplice della stima dell'intera implementazione di una storia completa, ma in un certo senso stiamo semplicemente scambiando un approccio alla stima per un approccio più semplice con meno fedeltà.

Questa è la mia ipotesi su cosa potrebbe significare:

Se si dispone di più di unittest che coprono i diversi scenari (nell'esempio di login: l'utente ha un account, non è bloccato, la password è corretta, ...) allora potrebbe essere ok avere solo un test di accettazione (come una sorta di integrationtest).

Senza contesto questa affermazione è abbastanza inutile