Come organizzare il test di unità / integrazione in BDD

I prerequisiti sono la parte "Data" dell'equazione. Questo dovrebbe preferibilmente accedere direttamente al database e creare gli oggetti di cui hai bisogno. Quindi per il tuo caso:

Given user "whatf" exists
And user "whatf" has 3 blog posts
When "whatf" logs in
Then he should be shown a list of all his posts

Ora, step user "whatf" exists crea un utente nel database (chiamiamo l'utente in modo che possiamo avere una definizione specifica dell'utente dietro le quinte, in modo tale che tu non debba dire user exists with admin rights and pink theme and password "s3cret" ... su e oltre).

Step user "whatf" has 3 blog posts crea tre post nel database, contro il nuovo utente. Puoi essere più o meno specifico qui, se lo desideri. Più specifico ti dà flessibilità, meno specifico ti dà più passaggi riutilizzabili.

Il passo "whatf" logs in dovrebbe essere la prima volta che usi Selenium, per avviare il browser e accedere all'utente.

Quindi, nella fase di conferma, usi anche il selenio per verificare che l'utente sia shown a list of all his posts nella risposta.

Si noti inoltre che la differenza tra TDD e BDD è in realtà un dizionario. BDD incoraggia un linguaggio più orientato al comportamento per i tuoi test . Ma quei test possono ancora essere test unitari. Oppure possono essere test di accettazione ( ATDD ).

Ma la differenza tra ciò che chiamiamo un framework unit test (ad esempio xUnit) e ciò che chiamiamo un framework BDD (ad esempio Cetriolo) è molto più grande. Un framework BDD è definito molto più accuratamente un framework di test di accettazione, se vogliamo confrontarlo con un framework di test unitario. Esistono anche framework unit-test progettati con BDD in mente: li chiamiamo framework di test contesto / specifiche (al contrario di organizzare / agire / affermare).

Nello sviluppo del software solitamente si inizia con una specifica che, idealmente, proviene dal cliente. In quella specifica, tra le altre cose, troverai storie utente che definiscono il comportamento dell'applicazione. L'esempio che hai dato è un esempio di tale user story. È qui che entra in gioco BDD. Ti dà la lingua (Gherkin) e gli strumenti (Cucumber, SpecFlow, JBehave) che ti permettono, lo sviluppatore, di tradurre queste storie utente in caratteristiche e scenari che sono facili da capire da un non tecnico persona (ad esempio, clienti, stakeholder, ecc.) Questo ti dà la possibilità di addestrare una persona a scrivere queste specifiche, lasciando a te (oa un tester) il compito di implementare i test.

Per continuare sul tuo esempio, inizi a definire una funzione e uno scenario (o più), utilizzando la sintassi GWT (Given-When-Then):

Feature: Read blog
    In order to read the blog
    As a registered user
    I want to see a list of blog entries

Scenario: Access the blog
    Given: I am logged in (I am logged in as, if you plan on testing specific users)
    When: I navigate to the blog
    Then: I see a list of blog entries

In questo caso, Cucumber genererà test per ogni fase del tuo scenario. Nei test si scriverà un codice di automazione (Selenium) che farà agire il browser sul comportamento specificato nello scenario. Ciò è estremamente utile quando si desidera eseguire test di accettazione o test di regressione.