Perché la BDD consiglia un approccio all'aspetto esteriore al test?

Fai riferimento allo schema seguente:

SinoticheilloopTDDè"dentro" il ciclo BDD; ovvero, i passaggi 3.1, 3.2 e 3.3 del loop TDD formano l'intera fase 3 del ciclo BDD.

Questo è ciò che intendono per dentro-fuori e fuori-dentro. I TDD-ists fanno asserzioni nel ciclo interno; Le BDD passano i test di accettazione nel ciclo esterno.

The Onion è un'architettura, non un processo di sviluppo del software. Non ha nulla a che fare con BDD o con qualsiasi altro DD.

DDD non difende l'approccio verso l'esterno o verso l'esterno. Piuttosto è focalizzato sulla guida degli aspetti della progettazione e del modello del sistema dalle loro controparti nella vita reale nel dominio aziendale che si sta tentando di modellare. DDD riguarda i sistemi di modellazione.

Il BDD richiede ovviamente un approccio esterno e può integrare direttamente l'aspetto strategico del DDD (che riguarda i concetti di denominazione, linguaggio ubiquitario, comunicazione e organizzazione). La scrittura degli esempi / scenari è sia una pratica BDD che una DDD. Una tecnica collaborativa come Event Storming li porta entrambi insieme in una forma di analisi aziendale.

La ragione per cui BDD implica outside-in è perché l'idea centrale è guidare lo sviluppo dell'applicazione dal comportamento richiesto - il trucco è definire questo comportamento come scenario formale o esempio (comunemente nel formato Given / When / Then) che può essere usato per guidare letteralmente ogni fase della codifica. Questi esempi devono essere scritti in modo collaborativo e possono essere sviluppati dallo sviluppatore in modo iterativo prima di iniziare la codifica da essi.

Ciò a cui si finisce efficacemente, se si è riusciti a scrivere diversi esempi / scenari completi, è quasi un modello di dominio scritto come scenari di cetriolino. Il codice che scrivi poi, guidato da questi esempi, diventa effettivamente il tuo modello di dominio.