Capisco che sia meglio automatizzare le specifiche BDD sotto l'interfaccia utente quando possibile.
Ad esempio e citando dal libro di Gojko Adzic: Specifica per esempio :
Don't check business logic through the user interface
La mia domanda è quindi: Quali sono i casi d'uso specifici quando si utilizza il livello dell'interfaccia utente ha senso nel contesto di BDD?
Ci sono due casi distinti che potrebbero rientrare nella categoria di "usare l'interfaccia utente" che hai menzionato sopra, e hanno casi diversi quando avrebbe senso usarli:
1: specificare qualcosa usando i concetti, il linguaggio o gli elementi dell'interfaccia utente - casi d'uso specifici che giustificherebbero questa sarebbe una logica di rendering importante (si pensi alla visualizzazione del link di twitter - per esempio se l'intero link è inferiore a 100 caratteri, visualizza il link, altrimenti abbreviare, o posizionare gli elementi sullo schermo in base al numero di collegamenti di un articolo ecc.) o flussi di lavoro specifici per l'interfaccia utente critica / altamente rischiosa (navigazione, menu dinamici, ecc.). "critico / altamente rischioso" è la cosa cruciale qui, perché è molto facile pensare all'interfaccia utente e uno dei maggiori problemi che i nuovi team hanno tipicamente con le specifiche di stile BDD è quello di strafare dall'interfaccia utente, descrivendo cose che non sono così importanti termine
2: basta automatizzare i test attraverso l'interfaccia utente mentre le specifiche parlano ancora di funzionalità di base - ad esempio le specifiche parlano di consegna gratuita, ma l'automazione test sottostante utilizza il selenio per aprire un browser, caricare il sito web, acquistare libri, andare al checkout ecc (simile a quello che ho descritto nel pattern Three Layers link ). Casi d'uso specifici che giustificano questo sono i casi in cui il sistema è progettato in modo tale che il rischio sia distribuito nell'interfaccia utente e test sotto l'interfaccia utente non forniscano sufficiente fiducia alle parti interessate. Questo è principalmente un problema di progettazione del sistema legacy, e ho usato questo approccio quando ho adattato i test in stile BDD a un sistema legacy prima di una modifica importante o quando estendo un sistema legacy che contiene molto rischio o logica importante nell'interfaccia utente strato. Se si deve fare questo su un nuovo sistema, questo è in genere un segnale di rischio che non è localizzato e potrebbe indicare problemi con la progettazione del sistema.
Al di fuori dell'ambito del BDD, ma relativi a strumenti che le persone spesso usano per BDD, i test di scrittura (non le specifiche nel senso spec-by-example, ma solo l'automatizzazione dei test di regressione) attraverso l'interfaccia utente hanno anche senso nei casi dove il rischio è distribuito tra i diversi livelli, quindi l'esclusione dell'interfaccia utente dal test non fornirebbe sufficiente confidenza, o quando si desidera automatizzare un piccolo numero di test volti-salvati selezionati che inoltre rischieranno di compromettere i flussi di lavoro critici in tutti i componenti. Ad esempio, un'importante società di media aveva circa 10 test di questo tipo per il proprio sito Web principale. Questi test sono stati automatizzati usando cetriolo, perché è quello che gli sviluppatori potevano mantenere facilmente, ed erano molto frastagliati - quasi tutte le modifiche all'interfaccia utente li hanno rotti, ma poiché c'erano solo 10 di loro, i costi di manutenzione non erano così alti. Questi test sono stati descritti in termini di interfaccia utente e sono stati eseguiti tramite l'interfaccia utente per garantire la copertura più ampia possibile. Sono stati usati dagli sviluppatori come un rapido controllo che dovevano fare prima di dire che hanno finito con un pezzo di lavoro, oltre ai test delle unità tecniche e allo stile BDD.
Come hai detto, in generale ha molto senso evitare l'accoppiamento dell'interfaccia utente e della logica di business (non solo per scopi spec o test, ma anche per la manutenibilità) - l'interfaccia utente tende ad essere la parte più volatile del sistema ).
La mia opinione è che la verifica BDD nell'interfaccia utente abbia molto senso se la persona che scrive il test non è la persona che ha scritto l'applicazione. Oppure se desideri test più approfonditi per dimostrare che quando un utente accede alla tua applicazione, funzionerà davvero e vorresti davvero sapere che un percorso relativo a un servizio Ajax non è assolutamente infranto (o simili test unitari / BDD in il back-end non può mai trovare). Questo può rendere le implementazioni molto più semplici perché non sei seduto lì a chiedersi se centinaia di pagine effettivamente funzionino dopo aver inviato al server.
Hai chiesto un esempio specifico, quindi ecco qui.
Il mio vecchio collega ha creato un'applicazione web chiamata "parti di robot" disponibile su github
È testato in quasi tutti i modi in cui è possibile testare un'applicazione. Ha alcuni test dell'interfaccia utente codificati che sono molto BDD (sebbene non utilizzi un framework specifico BDD)
E prova il back-end con BDD (specflow)
Guardare attraverso questa applicazione può essere utile per vedere dove sono tracciate le linee tra UI / backend e unit test / BDD.
Qui ci sono alcuni test in cui l'interfaccia utente è testata in modo BDD