BDD e microservizi

Question

La nostra soluzione si basa sui microservizi. D'altra parte, il nostro CIO si aspetta che pratichiamo lo sviluppo basato sul comportamento su ogni nuova funzionalità.

È possibile gestire BDD in un'architettura di microservizi? In base alla tua esperienza, è una buona pratica adottare BDD contro tale architettura, o pensi che dovremmo guardare direttamente ai test di integrazione?

[EDIT]

Più precisamente, a mio parere, test BDD sono tenuti a verificare la logica di business, e solo la logica di business. In molti framework, gli scenari di BDD Tests sono creati dagli skateholder, con una DSL. I test BDD tendono a convergere verso pratiche esclusive di "Infrastructure Ignorant". D'altra parte, i test di integrazione dovrebbero verificare che la soluzione corrisponda all'infrastruttura di destinazione (sono fatti da DevOps?) E solo l'infrastruttura. Quando le funzioni aziendali sono "distribuite" su microservizi, dovresti prendere in giro quasi tutto (infra e business) nel tuo ambiente di test BDD (dovrebbe essere l'ambiente locale) e le imprese derisorie indeboliscono molto i tuoi obiettivi. Pensi che queste pratiche siano compatibili?

Answer 1

Perché pensi che BDD e test di integrazione sono diversi?

BDD significa semplicemente guidare il design attraverso il comportamento desiderato, solitamente espresso attraverso una serie di test di accettazione.

Questi test possono essere "test di integrazione" che coinvolgono molti [micro] servizi o possono essere test che specificano il comportamento desiderato di un singolo servizio o una singola classe in quel servizio. Idealmente ci sarà un mix di test a tutti questi livelli. L'importante è che tu specifichi il comportamento che vuoi e usalo per guidare lo sviluppo.

Il modo in cui il sistema viene implementato è, in una certa misura, irrilevante a condizione che mostri il comportamento previsto. Per i test di alto livello che trattano il sistema come una scatola nera, questo è vero e meno si va e più si avvicina al codice effettivo questo diventa meno vero (come si sta effettivamente testando l'implementazione in quel punto).

Quindi vorrei concentrarmi sul comportamento previsto dalle nuove funzionalità e scrivere le specifiche per questi test di accettazione, quindi implementare i servizi per soddisfare il comportamento richiesto aggiungendo test di livello inferiore secondo necessità in modo pragmatico, tenendo presente che Più basso è il livello dei test, più è probabile che siano fragili e che sia necessario modificarli mentre modifichi la tua implementazione.

EDIT

Basato sulla sua domanda di modifica.

Non sono d'accordo che i test BDD dovrebbero testare solo la logica di business. In effetti, è normale che i test BDD siano più focalizzati sulla verifica del sistema nel suo complesso, con tutte le parti integrate insieme. Detto questo, il BDD è solo uno stile di test che specifica il comportamento desiderato e può essere applicato a qualsiasi livello dell'applicazione. È possibile testare una singola classe specificando il comportamento usando la sintassi Gherkin e talvolta lo facciamo. specifichiamo anche il comportamento previsto dell'intero sistema utilizzando Gherkin e il comportamento previsto dei nostri servizi individualmente. Questi test saranno naturalmente in un formato leggermente diverso a seconda del livello che stiamo prendendo di mira.

Per i test di sistema potremmo avere specifiche in questo modo:

Scenario: user can perform action A 
    Given I am a user with access to some feature A 
    And feature A is enabled for the user 
    When I call perform action A with parameters 'Bob' and 'John' 
    Then A 'BobJohn' is created 
    And notifications are sent to the current user 

per i singoli servizi che potremmo avere prove come

Scenario: create messages are handled correctly 
    Given the service is set up 
    When a message arrives to create a 'BobJohn' 
    Then a new entry is added to the database with the key 'BobJohn' 
    And an outgoing notification message for 'BobJohn' is created 

Per singole classi potremmo avere prove come

Scenario: Notifier class should send notifications via all users preferred means 
    Given the current user wants notification by Twitter 
    And the current user who wants notification by email 
    When I send the notification 'BobJohn' to the current user 
    Then the twitter notifier should be invoked with 'BobJohn' 
    And the email notifier should be invoked with 'BobJohn' 

Questi sono tutti test in stile BDD ma testano aspetti diversi del sistema tem.

Answer 2

penso che questo articolo potrebbe aiutare: Software architecture provides boundaries for TDD, BDD, DDD, RDD and clean code

Answer 3

Credo che la possibilità di eseguire test funzionali su un servizio sia un buon indicatore di qualità. I test di integrazione sono costosi, lenti e dolorosi. Il test di integrazione non è il luogo per stabilire se il tuo comportamento è corretto, il suo scopo storico è quello di indicare se i componenti interagiscono correttamente.