Unit Test Friendly Domain Driven Design

Question

Unit Test Friendly Domain Driven Design

#1 da (3 voti)
#2 da (1 voti)

6

Molte delle letture che ho fatto su DDD, sia nei libri che online, sembrano rappresentare un codice che, spesso, è difficile o impossibile da testare. Ad esempio, vi sono numerosi esempi con fabbriche statiche, chiamate a classi di dominio concreti e metodi di estensione statici (solo in esempi C #). Trovo frustrante e gravoso dover rivedere costantemente il codice per renderlo testabile nella mia mente.

Qualcuno può suggerire materiale che dimostri il codice DDD con il 100% di testabilità in mente (preferibilmente in C #)?

Inoltre, per meandro un po ':

Il fatto che molti dei campioni di codice non siano un segno di prova (odore) che il DDD sta diventando obsoleto?

tdd unit-testing domain-driven-design

posta drogon 30.01.2013 - 19:40

fonte

2 risposte

Leggi altre domande sui tag tdd unit-testing domain-driven-design

C'è qualche licenza ben conosciuta che richiede di rendere disponibili le modifiche quando viene pubblicato solo * output * derivato? Importanza di diffing e merging per la documentazione delle specifiche di progettazione

score 3 · Answer 1

Is the fact that many of the code samples are not test-friendly a sign (smell) that DDD is becoming antiquated?

Non ci credo. Direi che è un segno che chiunque abbia fornito i campioni di codice DDD puzzolenti si è concentrato su questo e non sui test unitari. Non è difficile trasformare quel codice in ciò che è creato con questi fini in mente.

Ora non intendo dire troppo il mio corno, ma sentitevi liberi di dare un'occhiata a questa domanda e la mia risposta sulla revisione del codice . Penso di aver preso un codice DDD abbastanza comune e l'ho montato in uno stato almeno testabile (forse non al 100% di testabilità, ma decisamente di più).

Ho anche partecipato a un paio di presentazioni DDD da Stephen A. Bohlen e there's un blog con un link ad alcuni dei suoi codici e diapositive. Ho preso quel codice e ho fatto un refactoring molto simile a quello che ho fatto sulla risposta CR.

score 1 · Answer 2

Non è DDD essenzialmente 'top down' progetta e perfeziona un modello basato sulla conoscenza / esperienza del dominio.

Mentre il TDD è un programma dal basso verso l'alto, il processo di refactoring è influenzato e incoraggia il disaccoppiamento a migliorare la capacità di test.

Così come questi sono in disaccordo tra loro ... Credo sia difficile dimostrare il codice DDD con il 100% di capacità di test.

Credo che sia impossibile raggiungere un'abilità di prova del 100%, quindi cerco sempre un 70-90%.