BDD e comportamento basato sullo stato complesso

Naviga le tue risposte
4

Mi sto chiedendo come scrivere casi di test BDD per un sistema reale. Tutti gli esempi che riesco a trovare sono banali e non rispondono alla domanda.

Il caso d'uso / storia di esempio è fondamentalmente simile a questo:

  1. L'utente si trova nella pagina principale dell'applicazione
  2. Fa clic su recupera per recuperare qualche ordine su cui lavorare
  3. Riempie 4 caselle di testo e invia invia.
  4. Accade qualcosa
  5. Il prossimo ordine è presentato all'utente

Quindi, il punto 4 è un po 'vago, ma c'è molta logica in gioco, c'è un flusso di lavoro sotto, ecc. In pratica puoi definirlo in questo modo: 

Given order of types A+B+C+E+F (20 possible values with arbitraty combination)
  and subtype a1 and the order has attribute X = 1, attribute Y=asdasd, (and much more)
When user enters some specific kind of value in here, and other in here and clicks submit
Then order does this, this, this, this, this, this and that

Non ha un bell'aspetto ...

Quindi l'altro modo è scrivere: 

Given the order with type A (and the rest is "default")
When user does ...
Then the order does things-depentant-only-on-A

Sembra più bello, ma - è davvero l'approccio giusto per definire quello "stato predefinito" del sistema? Non può essere arbitrario perché "cose-dipendenti-solo-su-A" non sono realmente indipendenti - potrebbero non avere nemmeno la possibilità di calciare se l'indicatore "non-prendere-A-dentro-conto" è attivo, o qualsiasi altro caso strano strano. (sì, il mio progetto attuale è: una logica non troppo complessa + anni-uomo di casi speciali)

Una nota: quando descriviamo i requisiti a volte specificiamo i parametri necessari perché la storia abbia un senso, a volte no - funziona per noi, perché conosciamo altre storie. Ma in BDD sembra che il test case dovrebbe essere specifico e inequivocabile.

    
posta mabn 03.08.2013 - 01:26
fonte

2 risposte

5

Dovresti descriverlo usando la terminologia che ha senso per l'azienda, non per un client HTTP. Ad esempio, 

Scenario: Mark Order as Pending
  Given we have an Order Y        // creates order
   When the user edits Order Y    // click/load edit page
    And marks it for review       // toggles tickbox #3
   Then it should show up in the pending review list

BDD si occupa solo di descrivere il comportamento previsto. Concentrati meno sulla descrizione dell'implementazione. Mentre il secondo è più facile, e in genere ciò che vedi nei tutorial, ti ritrovi con una tonnellata di ripetizioni e test di confusione.

    
risposta data 03.08.2013 - 03:16
fonte
0

Quindi, se ti capisco correttamente, mi stai chiedendo come possiamo formulare i nostri scenari di cetriolino in modo tale che stiamo coprendo solo una cosa mentre il problema è che il risultato dipende in realtà da diverse cose.

Penso che un esempio di questo sarebbe qualcosa di simile - un sistema di prenotazione di tavoli con le regole: non è possibile prenotare nei fine settimana e l'età dell'utente deve essere 18 +

Il When step è il comando che diamo al sistema - ad es. tabella del libro

Quindi lo scenario dovrebbe specificare nel passaggio Given con informazioni sull'ora corrente (ad esempio, non il fine settimana) e l'età dell'utente (18), anche se sei interessato solo al tuo scenario che copre la regola one - cosa succede quando l'utente ha meno di 18 anni

Una soluzione è spostare il passo di circa Given the current date is x/y/z in Background in modo che venga eseguito prima di ogni scenario e rendere questo file funzione solo sulla regola dell'età.

Quindi dovresti creare un altro file di caratteristiche con il passaggio Given Mark was born on /x/y/z/ messo in secondo piano in modo che ogni scenario sia specifico per le date di fine settimana e non di fine settimana.

In questo modo Then è "dipendente" solo Given nello scenario. (anche se in realtà non è indipendente - ma il test per gli altri fattori viene testato altrove e quindi può essere concettualmente "ignorato")

E solo per chiarire qualcosa - il Then , il risultato è essenzialmente un nuovo stato in cui si trova il sistema. Questo "qualcosa accade" nel tuo passo (4) significa che qualcosa cambia nello stato dei sistemi. Quindi non sarebbe next order presented to user ma cosa è cambiato nel sistema come risultato del comando When - ad esempio il tuo prossimo order id potrebbe essere stato incrementato, potrebbe essere stata inviata una notifica, lo stock potrebbe essere stato aggiornato ecc. Queste sono le cose che ti interessano.

Per quanto riguarda la presentazione all'utente finale, il BDD non ha molto da dire e spesso si applica in modo errato. Diciamo che la regola aziendale per sys-admins è quando vanno su www / order / enter - sono always presentati con un modulo usando l'id ordine corrente / ultimo incrementato. Puoi scrivere un test molto semplice (integrazione) per verificarlo.

Il fatto che il modulo sia corretto, almeno nel senso che contiene gli elementi di input corretti, può essere verificato eseguendo il comando When tramite il browser (automatizza il browser) - se si ottiene il risultato corretto ( DB o stato del sistema), quindi il modulo funziona correttamente per quanto riguarda l'input dell'utente.

    
risposta data 17.10.2018 - 14:22
fonte

Leggi altre domande sui tag

Scrittura della mappa dei dati in XML in base a un formato definito dall'utente Modello dell'unità di lavoro