Il BDD / TDD implica un client automatizzabile?

Question

Il BDD / TDD implica un client automatizzabile?

#1 da (4 voti)
#2 da (1 voti)

6

Sono d'accordo con tutte le idee fondamentali del BDD e cerco di usarlo il più possibile. Tuttavia, una cosa che mi colpisce è che l'esterno nello sviluppo e i test che esprimono uno scenario devono avere il controllo sul cliente.

Il termine esterno in sviluppo si riferisce alla pratica dello sviluppo di software scrivendo per prima cosa test di livello / livello alto e utilizzandoli come guida per implementare funzionalità. Per un'eccellente guida a questo approccio, consulta il libro Growing Object Oriented Software (GOOS) .

Pertanto, i framework di automazione del client Web e gli strumenti di automazione dell'interfaccia utente desktop diventano un componente chiave di BDD / TDD.

Nel mio caso, sviluppo software di middle-tier e back-end, quindi i client del mio software sono di solito livelli di servizio come Undertow o Tomcat ecc. o eseguibili autonomi che consumano il mio codice sotto forma di libreria.

In questo caso, mi trovo a scrivere codice che descrive ciò che fa il client come client.ConfirmsMessagesAreInTheQueue(); Sono d'accordo con questo, perché mi fa pensare e implementare il modo in cui un client interagisce con il mio codice, ma mi fa anche pensare che non importa quale sia l'architettura a portata di mano, BDD presuppone che ci sia un client automatico o io devi scriverne uno Altrimenti, non posso descrivere una funzionalità senza alcun tipo di interazione con il client, che può essere un'interfaccia utente gestita dall'utente o un pezzo di codice che viene eseguito come servizio.

Ho capito bene? È questa la norma per BDD / TDD?

Aggiornamento: Devo confessare che mi sono un po 'troppo concentrato sugli scenari in cui l'automazione dell'interfaccia utente è inclusa nell'oscilloscopio BDD. Un esempio molto comune di questo è quando il selenio viene utilizzato per automatizzare l'interazione dell'interfaccia utente nei test end-to-end. Certo, questa non è la definizione dell'ambito per BDD. Questo post del blog sembra fare la distinzione benissimo.

tdd bdd

posta mahonya 26.03.2017 - 11:20

fonte

2 risposte

1

Il comportamento del software non dipende da un'interfaccia grafica utente. Comportamento di test significa che dato un determinato input e una certa procedura otterrai un certo output.

L'output potrebbe essere un'interfaccia utente o JSON.

Ciò che il client fa con quell'output dipende dal cliente. Dovrebbero avere i loro test BDD. I test devono solo verificare la tua fine del contratto, non i loro

@mahonya ha commentato:

Please take a look at the definition of Acceptance tests and acceptance test driven development. End to end testing includes UI or other clients all the time. It is very much part of the BDD.

Mentre i test di accettazione fanno parte di Behavioral Driven Developement, non sono l'intero ambito del BDD, né i test di accettazione delle doe implicano un'interfaccia grafica utente.

Da Wikipedia :

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.

(enfasi, mia)

Si noti che questa definizione non limita il codice sottoposto a test. Test unitari, test di integrazione, test di accettazione - tutti questi fanno parte di BDD. Niente di tutto ciò implica un client che può essere automatizzato. In effetti, gran parte della descrizione di BDD consiste nel rendere tutti i tipi di test "leggibili", non solo i test di integrazione / accettazione completi che guidano un'interfaccia utente.

risposta data 26.03.2017 - 15:11

fonte

Leggi altre domande sui tag tdd bdd

Che cos'è zfreeze e cosa ha reso così difficile emulare? Se ho un caso con 2 sottocasi dovrei usare 1 o 2 casi d'uso?

score 4 · Accepted Answer

tests that express a scenario need to have control over the client

I test sono a client. Non esiste "il cliente".

Un cliente che utilizza un servizio fa affidamento su quel servizio che presenta un determinato comportamento. Un test, che si tratti di unità, integrazione, accettazione, qualsiasi cosa, è un tentativo di confermare che i comportamenti effettivi e attesi del servizio sono gli stessi.

Un test assume il ruolo di un cliente quando parla e ascolta il servizio allo stesso modo di qualsiasi altro client. In questo modo un servizio sotto test può semplicemente fare ciò che fa sempre.

Perché funzioni, il servizio deve consentire a diversi clienti di parlarci. Quando le persone parlano del codice testabile è quello che intendono dire.

Quindi i test non hanno bisogno di avere "controllo sul client". Devono essere un client che può essere scambiato per sostituire i client "operativi".