BDD è realmente applicabile al livello dell'interfaccia utente?

Question

BDD è una metodologia "outside-in", che, a quanto ho capito, significa che inizi con ciò che sai. Scrivi le tue storie e scenari e poi implementa gli oggetti di dominio più esterni, spostando "verso l'interno" e "deliberatamente" scoprendo i collaboratori mentre scorri attraverso livelli di servizio, livelli di dominio, ecc. Per un collaboratore che non esiste ancora, ti prendi in giro (o "fingi") finché non lo fai. (Sto rubando alcuni di questi termini direttamente da Dan North e Kent Beck).

Quindi, come si inserisce una UI?

Prendendo in prestito da una delle Nord di blog entries, egli riscrive questo:

Given an unauthenticated user 
When the user tries to navigate to the welcome page 
Then they should be redirected to the login page 
When the user enters a valid name in the Name field 
And the user enters the corresponding password in the Password field 
And the user presses the Login button 
Then they should be directed to the welcome page 

in questo:

Given an unauthenticated user 
When the user tries to access a restricted asset 
Then they should be directed to a login page 
When the user submits valid credentials 
Then they should be redirected back to the restricted content 

Egli fa questo per eliminare la lingua dai domini non rilevanti, uno dei quali è l'interfaccia utente ("Campo nome", "Campo password", "Pulsante Login"). Ora l'interfaccia utente può cambiare e la storia (o meglio, l'intento della storia) non si interrompe.

Quindi quando scrivo l'implementazione per questa storia, utilizzo l'interfaccia utente o no? È meglio attivare un browser ed eseguire "l'utente invia credenziali valide" tramite un test del selenio, o per connettersi direttamente all'implementazione sottostante (come un servizio di autenticazione)? A proposito, sto usando jBehave come il mio framework BDD, ma potrebbe altrettanto facilmente essere Cucumber, rSpec, o un numero di altri.

Tendo a non testare l'interfaccia utente in modo automatico e sono cauto con gli strumenti di automazione della GUI come Selenium perché ritengo che i test (1) possano essere eccessivamente fragili e (2) essere eseguiti dove il costo dell'esecuzione è il più grande. Quindi la mia inclinazione è quella di testare manualmente l'interfaccia utente per l'estetica e l'usabilità e lasciare la logica di business a livelli inferiori, più facilmente automatizzabili. (E possibilmente strati meno probabili cambiare.)

Ma io sono aperto a essere convertito su questo. Quindi, è BDD per l'interfaccia utente o no?

PS. Ho letto tutti i post su SO che ho trovato su questo argomento, e nessuno in realtà ha risposto alla mia domanda. This one si avvicina di più, ma non sto parlando di separare l'interfaccia utente in una storia separata; piuttosto, sto parlando di ignorarlo interamente ai fini del BDD.

Answer 1

La maggior parte delle persone che utilizzano strumenti BDD automatizzati lo utilizza sul livello dell'interfaccia utente. Ho visto alcuni team portarlo al livello successivo - il livello del controller o del presentatore - perché la loro interfaccia utente cambia troppo frequentemente. Un team è stato automatizzato dall'interfaccia utente sul proprio sito rivolto ai clienti e dal controller sul sito di amministrazione, poiché se si fosse verificato un problema potrebbe facilmente risolverlo.

Principalmente BDD è progettato per aiutarti a conversare in modo chiaro e inequivocabile con i tuoi stakeholder (o per aiutarti a scoprire i luoghi in cui l'ambiguità esiste ancora!) E portare la lingua nel codice. Le conversazioni sono molto più importanti degli strumenti.

Se si utilizza il linguaggio che l'azienda utilizza per scrivere i passaggi e mantenerli ad un livello elevato come suggerisce Dan, essi dovrebbero essere molto meno fragili e più facilmente mantenibili. Questi scenari non sono realmente test; sono esempi di come utilizzerai il sistema, che puoi usare in conversazione, e che ti danno test come un buon sottoprodotto. Avere le conversazioni attorno agli esempi è più importante dell'automazione, qualunque sia il livello in cui lo si fa.

Direi che se l'interfaccia utente è stabile, provare l'automazione e, se non funziona, scendere a un livello inferiore o assicurarsi di disporre di test manuali sufficienti. Se stai testando comunque l'estetica che ti aiuterà (e mai, mai usare l'automazione per testare l'estetica!) Se la tua interfaccia utente non è stabile, non automatizzarla - stai solo aggiungendo impegno a qualcosa che probabilmente sai fare cambiare, e l'automazione in quel caso lo renderà più difficile.

Answer 2

Sono nuovo di BDD da solo, ma ho trovato il sito cuke4ninja per aiutare in questo senso. Quello che suggeriscono (la mia interpretazione) è che hai le tue definizioni passo alto e agonistico dell'interfaccia utente, che chiama in una classe "workflow" che raggruppa i dettagli come "fai clic su questo pulsante", "popola questo campo" in un metodo che cattura il flusso di lavoro in prova, che chiama una classe "screen driver" che gestisce l'automazione dell'interfaccia utente per quella schermata specifica. In questo modo tutto il codice di automazione dell'interfaccia utente è astratto rispetto alle definizioni di passo e si trovano in un'unica posizione, e se l'interfaccia utente cambia, devi solo cambiare il codice nel "driver dello schermo" invece di tutti i test multipli. Here è la pagina pertinente in cui viene discussa.