TDD, DDD e incapsulamento

Question

Dopo diversi anni di seguito alla cattiva pratica tramandata da 'architetti' al mio posto di lavoro e pensare che ci deve essere un modo migliore, ho recentemente leggendo intorno TDD e DDD e credo che i principi e le pratiche sarebbe una grande misura per la complessità del software che scriviamo.

Tuttavia, molti dei campioni TDD ho visto chiamare un metodo sull'oggetto dominio e quindi testare proprietà dell'oggetto per garantire il comportamento eseguito correttamente.

D'altra parte, molte persone autorevoli esperti del settore (Greg Young più evidente così con i suoi colloqui sul CQRS), l'avvocato completamente incapsulare ogni oggetto del dominio, eliminando tutti i 'getter'.

La mia domanda quindi è: come si può verificare la funzionalità di un oggetto di dominio se è fatto divieto di recuperare il suo stato

?

Credo che mi manca qualcosa di fondamentale quindi non esitate a chiamare me un idiota e mi illumini -. Alcun orientamento sarebbe molto apprezzato

Answer 1

Quello che stai descrivendo è verifica dello stato in cui si assert sullo stato dell'oggetto dominio. C'è un ramo di TDD che si chiama verifica comportamento che utilizza oggetti Mock.

la verifica del comportamento consente di specificare quali metodi dovrebbe essere chiamato e se si vuole, che i metodi non sono chiamati.

Se vuoi in questo articolo di Martin Fowler per maggiori dettagli: Mocks non sono stub .

Answer 2

OK, questa risposta è di un anno troppo tardi; -)

Ma quando si desidera testare modelli CQRS, è possibile fare affermazioni sui fatti di dominio sparati invece di affermazioni sullo stato di entità.

es. se si desidera verificare se chiamate:. customer.Rename ( "foo") determina il comportamento corretto

Invece di prova se customer.Name è uguale a "foo", è piuttosto verificare se c'è un evento CustomerRename in attesa con il valore "Foo" nel tuo negozio evento in sospeso. (Nel vostro UOW o nella vostra lista degli eventi entità a seconda realizzazione)

Answer 3

Se sei veramente intenzione di andare fino al punto di vietare il recupero dello stato, allora si sarà limitato a test comportamentali, probabilmente attraverso un quadro di scherno, come TypeMock, che ha il potere di monitorare il comportamento del vostro oggetto. Se siete in grado di fare pura BDD, quindi in teoria si può far valere la correttezza di tutto il sistema solo per il modo in cui è comportarsi.

In pratica, ho trovato BDD ad essere più fragili in un sacco di casi di test solo stateful. Mentre alcune persone potrebbero richiedere una certa teoria, funziona solo se funziona per voi. test basato Stato-fa ancora il 90% di tutti i test di unità che scriviamo, e siamo ben consapevoli di BDD sulla nostra squadra.

Fate ciò che funziona meglio per voi.

Answer 4

Un paio di cose.

In primo luogo, quando si fanno le cose come TDD per rendere il codice testabile si finisce con classe più piccola. Se si dispone di una classe con un sacco di proprietà private, non è possibile controllare, c'è una buona probabilità che potrebbe essere suddiviso in più classi e reso più verificabili.

In secondo luogo, l'architettura OO oldschool cerca di rendere il software di sicurezza utilizzando garanzie lingua per evitare che le cose ad essere accessibili. Un'architettura TDD rende il software più robusto scrivendo test che verificano quello che fa in realtà il codice, mettendo meno enfasi sull'utilizzo di costrutti di linguaggio per garantire quello che il programma non fa.

Ultimo, il controllo di una proprietà non è l'unico modo per convalidare il codice ha fatto quello che doveva fare. Il libro xUnit Design Patterns documenti diversi approcci qui: http://xunitpatterns.com/Result%20Verification% 20Patterns.html

Answer 5

chiamo metodi di input pubbliche di un sistema (cioè I spingere dati di ingresso nel sistema), quindi ottengo (e sostengo) l'uscita del sistema. Non sto testando stato interno del sistema, ma piuttosto il suo comportamento pubblico / visibile: Qualora una prova implementazione interna, o testare solo il comportamento del pubblico?

Answer 6

Che cosa si parla si chiama test di Stato. C'è anche il test comportamento. Le tecniche utilizzate per questo sono Dependency Injection, Inversion Of Control, e beffardo:

Tutti gli effetti collaterali della vostra classe sono implementate come chiamate di metodo sulle sue "dipendenze" - vale a dire oggetti forniti dall'esterno, di solito nel costruttore. Poi, nella vostra unità-test, si fornisce un oggetto falso al posto di uno vero. L'oggetto falso in grado di ricordare se certo metodo è stato chiamato, e questo è quello che si affermi nel tuo test.

Esistono diversi quadri Mocking che automatizzano la creazione oggetto fittizio generando dinamicamente classi che implementano una data interfaccia. I più popolari sono Rhino.Mocks e Moq.

Answer 7

Ehi Justin, come te, mi è stato recentemente pensando di aggiungere getter al mio oggetto di dominio di sola scrittura per il bene di unit test, ma ora sono convinto che mi sbagliavo. Supponendo che hai comprato l'idea di un dominio di sola scrittura, in primo luogo, quindi se avete getter a tutti, siete in cerca di guai. Il principio di dominio di sola scrittura vorrebbe di sparare un evento dal oggetto di dominio, o leggere da una proiezione che l'oggetto del dominio ha scritto, o qualcosa del genere. Una volta che esporre getter stai iniziando a esporre "forma" dell'oggetto, e come dice Greg Young, "oggetti di dominio hanno un comportamento, non Forma".

Detto questo, sto lottando con la stessa domanda ... come si fa a unità di prova di un oggetto di dominio di sola scrittura? Ecco il mio piano attuale: Sto pensando di fare il mio fuoco oggetto di dominio di un evento di dominio che dice "Queste proprietà cambiato", e nel mio test di unità, mi iscrivo per questo prima di inviare il "EditCommand". Scopri post di Udi Dahan sul dominio Eventi qui , e anche vedere quello che dice Eric Evans su Domain Eventi .

Answer 8

Mi chiedevo la stessa cosa fino a quando ho finalmente imbattuto sui seguenti documenti. Li ho trovati ad essere grandi primer su come eseguire la verifica comportamento, specialmente il primo avermi diversi "momenti aha":

1. Utilizzando Mocks e Test per progettare basati su ruoli oggetti
2. Ruoli Mock, non oggetti