Ho bisogno di qualche consiglio per fare i passi per TDD. Come pensiamo in termini di interfacce per tutto quando scriviamo il codice? La maggior parte dei libri di prova ti dice come scrivere test. Ma voglio un libro che indichi quale sia il modo migliore per scrivere codice in termini di TDD
How do we think in terms of interfaces for everything when we are writing code?
Alcune delle altre risposte hanno toccato il giusto corso di progettazione, ma l'assunto non dichiarato nella domanda è sottile e imperfetto e merita di essere trascinato a calci e urla nella dura luce del giorno .
È comune leggere su TDD e pensare "sì, è una grande idea" e poi non farlo . Invece, è facile ricorrere alle prime abitudini del codice e poi chiedersi come si suppone di dover pensare a tutte le interfacce necessarie e convenienti mentre si scrive il codice. Non farlo!
Scrivere il test prima ti costringe a inventare l'interfaccia prima tu scrivi il codice. Quindi non stai pensando al codice affatto , stai pensando all'interfaccia per testare il codice.
TDD esegue il test delle funzioni, non delle unità. Sentiti libero di aggiungere test unitari e copertura del codice se vuoi, ma tutto ciò che TDD richiede è che ogni funzione abbia test automatici. [Ma guarda in BDD per una specifica di test ancora più semplice]
Questo processo creerà le interfacce, farà funzionare il codice, quindi perfezionerà le interfacce e il codice, in modo incrementale.
Se trovi durante la fase di refactoring che, per esempio, l'iniezione di dipendenza (DI) semplificherebbe il design, ottimo, usalo. Ma non iniziare con DI o qualsiasi altra tattica / tecnica come un martello preferenziale. Lascia che il codice sia la tua guida e lascia che il design evolva in modo naturale, un test alla volta.
Uno dei più grandi modi per rendere testabile il codice è utilizzare Iniezione di dipendenza . Ciò ti consente di avere un'implementazione predefinita della logica di programmazione, ma quando vai a test, puoi prendere in giro l'implementazione per facilitare i test.
public interface Model {
//methods
}
public class DefaultModel : Model {
//default implementation
}
public class Worker {
private Model _model;
public Worker(Model model) {
_model = model;
}
public void DoSomething() {
var result = _model.Action();
//...
}
}
//real code
Worker worker = new Worker(new DefaultModel());
//test code
public class TestModel : Model {
//code for testing
}
Worker worker = new Worker(new TestModel());
//do testing of worker
Seguendo questo modello, puoi testare Worker senza la reale implementazione di DefaultModel e cose su cui potrebbe dipendere. Dovresti quindi eseguire test separati per garantire che DefaultModel sia corretto.
Ecco un discorso tecnico che riguarda scrittura del codice verificabile . Non l'ho visto, ma ne ho visto uno dato dallo stesso ragazzo. Non sono riuscito a trovare un collegamento per quello che ho guardato.
I principi di TDD sono inerenti al suo nome. La prima cosa da tenere a mente è, prima prova.
Quando scrivi un test che eserciterà un nuovo oggetto o metodo precedentemente non scritto, stai sostanzialmente definendo l'uso (tradotto: interfaccia) per quel nuovo pezzo di codice. Ciò ti costringe ad esaminare come vorresti usare questo codice, che è fondamentale per una buona progettazione.
TDD incoraggia anche un modo di pensare a Responsabilità Singola. È necessaria una nuova funzionalità che verrà eseguita ogni minuto, ottenere alcuni dati dal DB, eseguire calcoli complessi arbitrariamente, quindi riportare il risultato nel DB. Bene, la prima cosa di cui hai bisogno è un codice che verrà eseguito ogni minuto. Quindi crei un timer. Quindi, il timer deve ottenere qualcosa dal DB. Sembra una sua responsabilità, quindi prendi in giro l'uso di qualche oggetto lettore DB. Questo ti costringe a pensare a come vuoi usare quell'oggetto. Questo sistema intrinsecamente ricorsivo per definire l'uso di qualcosa di nuovo prima di definire che qualcosa di nuovo porta generalmente a prendere decisioni di progettazione decenti, o almeno facilmente riconducibili.
Per quanto riguarda strettamente le interfacce, non è proprio TDD, è solo un design "SOLIDO", in particolare aderenza al "principio di inversione di dipendenza" (in poche parole, "le classi dovrebbero sempre dipendere dalle astrazioni, mai da altre classi concrete" ). Se la classe BusinessLogicObject richiede che il codice scriva nel DB, non dovrebbe mai dipendere da un DBWriter di classe concreto, ma da un IDBWriter. Ciò promuove un "accoppiamento lento"; in questo modo, se in linea si desidera scambiare DBWriter per BetterDBWriter, quindi, fino a quando BetterDBWriter ha implementato la stessa interfaccia IDBWriter, non sarebbe necessario modificare BusinessLogicClass per creare o lavorare con BetterDBWriter.
A mio modesto parere hai bisogno di diverse abilità prima di poter diventare bravo a TDD.
Per prima cosa è necessario comprendere come costruire codice SOLID, Principi, modelli e pratiche agili in C # (Robert C. Martin) è perfetto per questo. Una breve introduzione è su DimeCast .
Hai anche bisogno della conoscenza del test delle unità
Rispetto alla conoscenza TDD:
E di quanto tu abbia letto tutta la conoscenza necessaria e hai bisogno di cambiare idea. E l'unico modo che conosco su come farlo è proprio facendo . Ottenere un allenatore sarebbe fantastico. Inoltre, per avere un'idea di come potrebbe funzionare il processo, potresti guardare gli screencast di James Shore " Lets play TDD ".
Dato che sei su .NET potresti voler vedere DNRTV con i primi episodi su TDD per avere una buona visione di ciò (e dare un'occhiata al pattern MVC).
JP Boodhoo passa attraverso TDD abbastanza chiaramente insieme al concetto di interfacce e iniezione di dipendenza in quei video e almeno mi ha aiutato a ottenere un groove su come farlo.
Il più grande punto di interface s nel codice di prova è l'idea di "cuciture" usate per "isolamento di prova".
Per il test dell'unità, devi essere in grado di isolare completamente il codice sotto test, quindi l'unico codice di produzione in esecuzione è quello sotto test. Per fare ciò dovrai sostituire altri oggetti con cui dipende con i falsi.
Per farlo rapidamente, esistono quadri di derisione e possono costruire velocemente oggetti falsi che implementano le interfacce di cui hai bisogno, in questo modo il tuo codice non dipende dal tipo concreto e un falso può essere passato al codice come parte del tuo chiamata di prova.
L'Iniezione delle dipendenze ha a che fare con l'assicurazione che il codice di produzione sa quale tipo concreto deve passare al tuo codice.
Leggi Pulisci codice di Robert C. Martin. Imparerai come scrivere un buon codice e anche il buon codice può essere facilmente testabile.