BDD, migliori pratiche di cetriolo

4

Sto cercando di capire alcune best practice quando si tratta di BDD e Cucumber . Solo di recente ho iniziato a usarlo, e la prima caratteristica per cui ho scritto un test sta testando una funzione di ricerca, in particolare come un livello Repository si integra con un% co_de JPA che è stato iniettato usando l'annotazione EntityManager . Lo fa da creando un EJBContainer usando la dipendenza di Maven incorporata GlassFish e inizializzando il livello di persistenza in questo modo. Funziona quindi sono abbastanza soddisfatto.

Ora sono nella fase in cui voglio iniziare a utilizzare Selenium con Cucumber per testare la funzione di ricerca della pagina JSF. Quale Presumo che sarò in grado di controllare il contenuto di una tabella HTML dopo che la ricerca è stata inviata.

È possibile utilizzare lo stesso file di funzionalità con una classe di passaggi diversi che esegue il test del selenio? È una buona pratica? Al momento nessuna di queste cose di Cucumber sembra un test unitario, sembra tutto un test di integrazione!

Quello che ho in mente è qualcosa come la seguente organizzazione

test
    |
    java
    |   |
    |   feature
    |       |
    |       web
    |       |  |
    |       |  user
    |       |      UserSearchWebSteps
    |       |      UserAddWebSteps
    |       |      UserDeleteWebSteps
    |       |      UserWebTest
    |       db
    |          |
    |          user
    |              UserSearchDBSteps
    |              UserAddDBSteps
    |              UserDeleteDBSteps
    |              UserDBTest
    resources
        |
        feature
            |
            user
                search_users.feature
                add_user.feature
                delete_user.feature

Quindi i passaggi sarebbero organizzati a livello di web o db, e quindi in questo esempio ogni passo dell'utente è sotto quello. Con una corrispondente classe di test per corridori che esegue tutti questi passaggi

E poiché i livelli web e db si aspettano gli stessi risultati, avrei condiviso i file delle funzionalità.

L'UserXXXTest dovrebbe quindi specificare nelle sue opzioni cetriolo dove trovare il file di funzionalità e perché i passaggi per il web e db sono separati a livello di pacakge avendo un metodo step con la stessa regexp non dovrebbe essere un problema.

@RunWith(Cucumber.class)
@CucumberOptions(features =
{
    "src/test/resources/feature/user"
})
public class UserDBTest
{

}
    
posta PDStat 03.07.2015 - 08:33
fonte

2 risposte

4

Tradizionalmente in BDD iniziamo con l'esterno e ci spostiamo, quindi avremmo una pagina web, quindi da lì passiamo alle connessioni DB effettive finché lo scenario non funzionerà con la pagina web.

Tuttavia, la tua domanda sull'opportunità di utilizzare lo stesso file di funzionalità con passaggi diversi a livelli diversi è appropriata e applicabile.

Al momento non penso che Cucumber lo faccia davvero. Behat per PHP fa. Il post di Konstantin Kudryashov su come modellare il dominio utilizzando gli stessi scenari end-to-end che funzionano attraverso il web layer potresti darti qualche idea su come fare bene questo genere di cose (versione breve: ricorda di rendere i tuoi scenari dichiarativi!)

Se volessi farlo in Cucumber, penso che sarebbe possibile se usassi link simbolici per rispecchiare i file delle funzioni che avresti voluto eseguire in entrambi i posti? Avrai bisogno di qualche pasticcio per farlo funzionare. Ma ... la teoria è molto solida, e Konstantin, che è un membro della comunità BDD molto rispettato, ha esplorato questo spazio per un po '.

Anche a livelli più bassi, però, non sarebbe un test unitario, ma un test di integrazione.

È possibile utilizzare BDD a livello di unità ( è iniziato lì, dopotutto ) ma probabilmente vorrai utilizzare qualcosa come RSpec piuttosto che i framework a livello di sistema più pesanti.

    
risposta data 16.07.2015 - 11:39
fonte
2

Credo che tu abbia frainteso un concetto fondamentale. Lo sviluppo guidato dal comportamento non è un test unitario. Se stai aspettando fino a dopo aver scritto il codice prima di creare il tuo file di funzionalità, stai sbagliando. Il vantaggio offerto da BDD è che il tuo business partner ti spiegherà come valuterà se il codice soddisfa o meno i requisiti prima che inizi a codificare. E questo è espresso come gli scenari nel file delle caratteristiche. Il tuo partner commerciale non tecnico dovrebbe essere in grado di leggere gli scenari e capire esattamente cosa viene testato. (In effetti, se lo stai facendo davvero bene, l'azienda sta scrivendo i file delle caratteristiche come risultato della riunione dei tre amigos.) Dovresti continuare a essere un'unità di test mentre esegui il codice. BDD = l'applicazione esegue il modo in cui l'azienda si aspetta di farlo. Unit Testing = il codice esegue il modo in cui lo sviluppatore si aspetta di farlo. C'è una differenza sottile ma incredibilmente importante tra questi due.

    
risposta data 07.07.2015 - 15:05
fonte

Leggi altre domande sui tag