Come gestire una catena di Whens o Thens in uno scenario?

In questo momento stai testando due requisiti:

• Un utente che non ha effettuato l'accesso deve accedere quando fa scorrere un'anteprima del messaggio
• Quando si scorre l'anteprima di un messaggio, l'utente dovrebbe essere indirizzato direttamente al messaggio

Se dovessi testarlo, eseguirò il primo test come parte di una funzione di accesso (che raggruppa i diversi scenari di accesso / disconnessione)

 Scenario: Log in an unauthenticated user opening the application
 Scenario: Log in an unauthenticated user swiping a preview
 Scenario: Log in an unauthenticated user tapping a notification in the bar
 add more here...

E vorrei testare lo scenario di anteprima dei messaggi senza occuparmi dell'accesso o della notifica (l'origine della notifica, il messaggio push, è irrilevante qui)

 Scenario: Take user directly to their message on swipe
 Given Dee receives a message preview on her locked phone screen
 When she swipes the preview
 Then she is taken directly to the specific message shown in the preview

Questo riduce entrambe le funzionalità al loro essenziale.

Suppongo che il primo scenario dovrebbe terminare con un riferimento a uno specifico secondo scenario come

...
Then she must "log-in-with-message-from-preview"

(il nome dovrebbe chiarire che non è il "solito accesso", ma una situazione più specifica).

Ora puoi descrivere questo secondo scenario senza ripetere tutte le precondizioni:

 Scenario: "log-in-with-message-from-preview"
 Given Dee is at the login 
 And she got a message from a preview before
 Then she is taken directly to the specific message shown in the preview

(Disclaimer: non ho esperienza con BDD finora.)

Per costruire sulle altre risposte, puoi suddividerlo in test più piccoli che dipendono l'uno dall'altro.

Given Dee has received a push notification

Questo sembra andare contro la natura di given poiché ricevere è un'interazione dell'utente. Potresti scrivere in questo modo:

Given Dee is sent a push notification

E il primo test sarebbe:

Given Dee is sent a push notification
When she receives the notification
Then the message preview appears on her locked phone screen

Un secondo test si basa sul primo test come precondizione:

Given she is logged out of Uluvit
When she swipes the preview
Then she is taken to the login screen

Un terzo test si basa sul secondo test come precondizione:

When she logs in
Then she is taken directly to the message shown in the preview

Esiste anche un quarto test implicito che si basa sul primo, ma non sul secondo o terzo:

Given she is logged in to Uluvit
When she swipes the preview
Then she is taken directly to the message shown in the preview

Il modo in cui esegui questi test l'uno sull'altro dipenderà dal framework che utilizzi. Alcuni framework consentono sezioni nidificate, dove l'intero scenario viene eseguito una volta per ogni sezione foglia, quindi l'intera cosa potrebbe essere scritta come:

Scenario: Take user directly to their message on swipe

1.  Given Dee is sent a push notification
    When she receives the notification
    Then the message preview appears on her locked phone screen

    2.  Given she is logged out of Uluvit
        When she swipes the preview
        Then she is taken to the login screen

        3.  When she logs in
            Then she is taken directly to the message shown in the preview

    4.  Given she is logged in to Uluvit
        When she swipes the preview
        Then she is taken directly to the message shown in the preview

... e l'ordine di esecuzione sarebbe 1, 2, 3 e poi 1, 4 .

In genere, raramente vedi più di 1 "quando" in uno scenario. Il "quando" sta esercitando il comportamento a cui sei interessato.

Come altri hanno pubblicato, hai due aspetti del comportamento qui:

• Gli utenti devono accedere prima che possano accedere ai contenuti sul telefono
• Gli utenti che utilizzano un'anteprima verranno portati a quell'anteprima quando accedono.

Quindi potresti sempre avere due scenari.

Tuttavia, ci sono un paio di volte in cui è OK per avere due whens (indipendentemente dal fatto che il tuo framework ti limiti deliberatamente a uno o no;

Va bene avere due whens quando hai un'interazione tra due diversi stakeholder o il tempo passa.

In questo caso, i comportamenti non sono separati. In realtà sono strongmente correlati. Uno di questi ha a che fare con un utente che vuole accedere al suo contenuto telefonico e l'altro ha a che fare con persone che vogliono che il contenuto sia sicuro (sia l'utente in un altro ruolo, sia potenzialmente un datore di lavoro). Puoi vederlo dal modo in cui il secondo requisito contiene il primo.

Quando parli con un esperto di dominio su questo, probabilmente non lo separeranno nemmeno quando corrono attraverso lo scenario. potrebbe eludere il fatto che si accede. In ogni caso, è perfettamente OK farlo come uno scenario. Puoi esplicitamente avere entrambi i whens:

When she swipes the preview
And logs in
Then she should be taken directly to the specific message shown in the preview.

Se decidi di andare con due scenari, vorrei che uno di loro perdesse il fatto che stava effettuando il login, e lo fa semplicemente come parte del passo in cui accede al messaggio, sia per l'accesso che per lo scorrimento:

When Dee accesses the message

E poi ne ha uno separato che richiama esplicitamente l'aspetto della sicurezza:

When Dee swipes the preview
Then she should be forced to log in before she can view it.

In realtà faranno la stessa cosa, il che li rende ridondanti, quindi tenderei ad adottare uno scenario per il pragmatismo e perdere il fatto che sta effettuando l'accesso (che va bene se è ovvio) o se ne hanno due "whens".

Si noti che poiché l'accesso è un aspetto del comportamento a cui si è attivamente interessati, dovrebbe essere sicuramente un quando e non un allora . Un sacco di gente pensa che si dovrebbe sempre avere un quando , ma non è il modo in cui le persone parlano quando i requisiti interagiscono, e BDD è stato progettato per catturare la conversazione, non per torturarla.