Sto imparando lo sviluppo del test guidato e leggo alcuni libri su TDD. Ho imparato le regole del test unitario. Come posso scrivere unit test, come posso selezionare i nomi dei metodi di test, Act, Assert, Action e così via.
In realtà ho sviluppato applicazioni con architettura a strati. Livello dominio, livello dati, livello servizio, livello interfaccia utente, ....
Come posso avviare un'applicazione con TDD. C'è una regola o un modo o altro. Ad esempio, avviando il Service Layer.
La dimensione di un progetto non dovrebbe fare alcuna differenza quando si fa lo sviluppo guidato da test. Il punto di test unitario è che stai testando unità di funzionalità completamente indipendenti da altre aree del codice.
Ciò si ottiene usando mock per simulare il comportamento previsto di altre parti del programma. Questo può essere ottenuto più facilmente codificando sempre su interfacce anziché tipi concreti.
Ad esempio, supponi di avere due classi ClassA e ClassB. ClassA chiama ClassB, ma si desidera testare ClassA in modo indipendente in quanto è un'unità separata da ClassB. Invece di fare riferimento direttamente a ClassB da ClassA, invece, rendi ClassB implement l'interfaccia IClassB. Quindi, durante la scrittura di unit test per ClassA, si semplifica semplicemente il comportamento dei metodi su IClassB. È quindi possibile procedere alla scrittura di test di unità isolati per ClassB.
Questo processo può essere facilitato con l'uso di injection dependance che consente di decidere il tipo di calcestruzzo previsto al runtime dell'applicazione .
Adottando questo approccio, stai solo testando singolarmente ogni singola parte del sistema, quindi non fa alcuna differenza da dove inizi. Questa è praticamente la definizione di test unitario.
Ciò che è probabilmente più importante all'inizio del progetto è scegliere un framework di simulazione e un'infrastruttura per le dipendenze che permetta di lavorare in questo modo. Ci sarà una varietà disponibile per qualunque lingua tu stia lavorando.
L'atto di testare più livelli del software allo stesso tempo è chiamato Test di integrazione . Non è ragionevole aspettarsi che questi test siano scritti a fondo prima che tutte le parti del sistema siano almeno sul posto (se non completamente).
Leggi altre domande sui tag tdd testing unit-testing domain-driven-design