Quando scrivo una funzione BDD, dovrei inserire l'interazione dell'utente precedente in un determinato passaggio o un passaggio quando?

Question

Sto cercando di scrivere requisiti per un processo aziendale in più fasi (tramite una procedura guidata). Ho molti scenari in cui le interazioni dell'utente con una schermata cambieranno se è consentito scegliere le opzioni su un'altra schermata.

Ad esempio (ho oscurato il business reale, ma il processo e la forma dei passaggi sono quasi identici):

Feature: Personal Diagnostic Search Filter
  In order to select a Technician who offers Personal Diagnostics,
    when I've asked for a Personal Diagnostic
  As a Business Customer
  I want to limit my search to Technicians who offer Personal Diagnostics

  Background:
    Given a Business named "Big Al's Auto Supply"
      And a Customer named "Bob Test" at the "Big Al's Auto Supply" Business
      And an Account named "bobtest@testbusiness.com" owned by "Bob Test"
      And the "bobtest@testbusiness.com" Account has the "Repair Order Creator"
        permission
      And you log in as "bobtest@testbusiness.com"
      And you start scheduling a new Repair Order

  Scenario: Enter the Select Technician page when Use PD is selected
    Given you select Use PD
    When you enter the Select Technician page
    Then the PD Filter should be visible
      And the PD Filter should be selected

  Scenario: Basic Search for Technicians when PD Filter is selected
    Given a Technician named "PD Technician"
      And the Technician named "PD Technician" supports PD
      And a Technician named "Non-PD Technician"
      And the Technician named "Non-PD Technician" does not support PD
      And you select Use PD
      And you enter the Select Technician page
      And you select the PD Filter
      And you select Basic Search
    When you search for Technicians with the name "Technician"
    Then your search results should contain "PD Technician"
      And your search results should not contain "Non-PD Technician"

Ma su Il wiki gherkin, si consiglia di: tu:

Evita di parlare dell'interazione dell'utente in doghens

Continuano a fare un'eccezione, però:

Accedi a un utente (un'eccezione alla raccomandazione di non interazione. Le cose che "sono successe prima" sono ok).

Si dice anche su quella pagina che:

Lo scopo di quando i passaggi è descrivere l'azione chiave che l'utente esegue

Cosa appartiene a un dato e cosa appartiene a quando se hai molta interazione dell'interfaccia utente?

Nel mio primo scenario, select Use PD Richiede l'interazione dell'interfaccia utente, in quanto fa parte della procedura guidata per la creazione di un nuovo ordine di riparazione. Tuttavia, è una preliminare per il filtro PD visibile e viene attivato quando l'utente inserisce la pagina del tecnico Seleziona.

Il primo scenario potrebbe non essere così male, ma il secondo scenario aggrava il problema. La ricerca viene attivata quando si colpisce Ricerca Ma ci sono molte interazioni dell'interfaccia utente che devono essere fatte per navigare a quella pagina. Alcune di queste interazioni non possono essere ridotte, come Use PD Deve essere selezionato affinché anche il filtro di ricerca appaia. Ma quelle interazioni dell'interfaccia utente non sono le Azione chiave dello scenario.

Answer 1

Come regola generale, cerca il più possibile a esprimere lo scenario come se stessi con una conversazione ed escludi quante più informazioni irrilevanti possibile.

Ad esempio, mi piacerebbe che i tuoi scenari sopra leggano qualcosa come:

Given our customer Bob Test is scheduling a repair order
And we have two technicians: "Fred Technician" and "George Nontechnician"
When Bob Test decides he wants a Personal Diagnostic
And he selects a technician
Then the search results should only contain "Fred Technician"

Quindi fai tutto ciò che è necessario per far funzionare tali passaggi, sia che si accedono o in altro modo. Si noti che non ho parlato di "pagine" o prese le misure effettive: dovrebbero essere intuitive per l'utente. BDD non riguarda i test. Si tratta di elaborare esempi di come le persone useranno il sistema, in modo da poter avere conversazioni attorno a quegli esempi ed esplorarli, trovare eccezioni e diversi scenari, ecc.

Verificare che il filtro sia visibile non è prezioso. All'utente non importa che il filtro sia visibile. Si preoccupa di poter usare il filtro per ottenere i suoi risultati, quindi fallo.

Nel codice, di solito passo un oggetto "mondo" tra i miei passi. Questo può togliere molto i Gubbins. Non ho usato molto Gherkin, ma immagino che fornisca un'abilità simile. Puoi archiviare tutti i dettagli dell'utente lì dentro, quali tecnici hai creato in modo da poterlo controllare non riporta "George non tecnico" nei risultati, ecc.

Anche l'uso di nomi amichevoli per i ruoli è utile, perché le persone possono quindi immaginare come sono Fred e George.

Sbarazzati di tutto ciò che non farà la differenza nello scenario e non aiuterà le persone a immaginare che accada. Sai che Bob ha il permesso di programmare un ordine perché è quello che sta facendo - basta aggiungere le cose necessarie a quel passaggio.

Il "quando" è il comportamento che sei interessato a descrivere. In questo caso, sei interessato alla capacità di filtrare per la diagnostica personale, quindi tutta l'interazione dell'utente associata al comportamento dovrebbe essere nel "quando", e tutte le precedenti interazioni dovrebbero essere in "donazioni". Trovo utile provare a pensare a un contesto in cui il risultato è diverso, ad esempio, cosa succede se non ci sono tecnici PD disponibili? Questo mi dice qual è la differenza; imposteremo un diverso contesto Ma eseguire lo stesso evento. Il contesto va nel dato, gli eventi vanno nel When. (Questo era molto più semplice prima dell'introduzione di "sfondo").

In generale, se i tuoi occhi glassa quando guardi uno scenario, stai facendo qualcosa di sbagliato.

Spero che sia di aiuto.