2010-07-13 9 views
7

Ho appena iniziato con BDD e sto provando a creare una piccola app, quindi posso vederla funzionare in un ambiente reale, ma ho difficoltà a decidere quale dovrebbe essere una funzionalità. Sto costruendo un piccolo negozio.BDD, cos'è una funzione?

Ho deciso che "Confronta prodotti" sarà una funzione e "L'utente può effettuare il checkout come ospite" sarà uno, ma per arrivare a questo, prima devo elencare i prodotti.

La mia domanda è, dovrebbe "Ci dovrebbe essere un elenco di prodotti" essere una funzionalità?

Grazie!

risposta

4

Probabilmente dovrebbe essere una funzionalità, ma provare a formularlo dal punto di vista dell'utente. Cosa offre questo elenco di prodotti?

  • L'utente dovrebbe essere in grado di avere una panoramica dei prodotti offerti
  • utente dovrebbe essere in grado di ordinare e riordinare prodotti sul nome, il prezzo, la disponibilità.
2

È piuttosto difficile iniziare a fare BDD. L'unica cosa che aiuta a sentirsi sicuri delle proprie capacità e l'intero approccio è scrivere scenari di test e il codice che li esegue. Ti suggerirei di non rendere più difficile la situazione già complessa e confusa. Scegli qualsiasi compito che devi attuare, apri un file di testo vuoto e prova a spiegare usando frasi semplici il comportamento. Ogni frase dovrebbe iniziare con una delle tre parole chiave: data, quando e quindi. Usando il tuo framework BDD preferito scrivi il codice che analizzerà queste frasi e stimolerà l'applicazione a entrare nello stato di avvio (dato), eseguirà alcuni comandi (quando) e asserirà lo stato di transizione (quindi). Il codice dell'applicazione può iniziare da semplici mock. Sostituisci gradualmente quelle porche con codice costruito gradualmente e fai crescere la tua applicazione con livelli di sicurezza e qualità più elevati.

1

La storia utente è una funzionalità. Qualcosa che può essere espresso in formato:

  • Come ruolo
  • vorrei fare qualcosa
  • In modo che obiettivo

Ad es

  • Come utente
  • Mi piacerebbe essere in grado di confrontare i prodotti
  • modo che io possa scegliere un prodotto che risponda alle mie esigenze in un modo migliore

  • Come ospite

  • I Vorrei fare il checkout al mio carrello
  • In modo da poter completare l'acquisto

Ogni funzione deve essere confermata da una serie di scenari Given-When-Then, ovviamente.

1

Stai praticamente chiedendo cos'è una funzionalità. Pensaci, hai una storia, una storia descrive una funzione che tu (o altre persone coinvolte) vogliono per la tua app. Di solito ha la forma di: Come utente voglio vedere l'elenco dei prodotti. Puoi aggiungere note a questa storia per renderla più chiara. Ma poi arriva il comportamento specifico (che alla fine si mette alla prova) - ci sono un numero infinito di comportamenti conformi a questa storia (si pensi alla visione dei prodotti e ai molti modi per presentarli). Il tuo obiettivo, in BDD, è trovare il comportamento di cui la tua app ha bisogno (uso app e non utente, perché a volte dovresti decidere per l'utente) - parlando con quante più persone possibili, provando cose e iterando è finita.

È come andare da cima a fondo - sempre cercando di concentrarsi sul comportamento - essere più specifici mentre si va. Se ci pensi, dato un comportamento (cioè un insieme di test) c'è un numero infinito di implementazioni. Ecco perché il focus di BDD è capire veramente il comportamento sperimentando e parlando: c'è sempre un grado di libertà.

1

Più importante sarebbe capire cosa l'utente vuole fare con l'elenco dei prodotti? la funzione fornirebbe qualcosa di prezioso per l'utente. Quindi nel tuo caso sarebbe

  • scegliere un prodotto per visualizzare da un elenco di prodotti
  • Scegli i prodotti x per confrontare da un elenco di prodotti
  • Altri
0

per determinare, se un requisito è una caratteristica esplicita/una storia utente, è possibile utilizzare le linee guida della progettazione/documentazione basata sull'attività (ad es. http://www.sprez.com/articles/task-documentation-design.html). Tali concetti riconoscono che un utente di un sistema desidera ottenere un risultato specifico. Di solito, per sapere qualcosa (ad esempio: quali prodotti sono disponibili) è solo un passo nel processo di acquisto/vendita/costruzione/ecc. Un buon punto di partenza in BDD è scrivere gli argomenti che useresti come capitoli nel tuo utente Manuale. Questi argomenti sono solitamente le funzionalità che fornirai nella tua soluzione software. Un buon framework che supporta un simile approccio di specifica per esempio è Concordion (http://concordion.org). Si prega di dare un'occhiata alla descrizione di "test di accettazione in inglese semplice" (http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/).