Costruire complessi algoritmi con TDD

TDD non sostituisce il design.

Questo è un malinteso comune sul TDD, che puoi in qualche modo "far crescere" un progetto coerente dal refattore rosso-verde. Non puoi I tuoi test devono ancora essere guidati dalle tue capacità di progettazione.

Se stai cercando di capire cosa fare tra l'input e l'output del tuo metodo sotto test, probabilmente significa che stai provando a fare troppo con un singolo metodo. Pensa a cosa dovrebbero fare quei passi intermedi. Scrivi test per quei passaggi intermedi e scrivi i metodi che superano quei test.

Si può usare TDD per algoritmi complessi. Scrivi numerosi test chiari ma significativi e usali per progettare il tuo programma. se c'è una randomizzazione usata nell'algoritmo, usa una sorta di iniezione di dipendenza e prova la randomizzazione separatamente. TDD è uno dei tanti metodi che utilizzerai per scrivere algoritmi di alta qualità: altri sono recensioni di codici, registrazione ecc.

I could write a test for the algorithm with an input and the expected output,

Non scrivere "un" test .. TDD non scrive un test alla volta. Scrivi prima più test che controllano i vari limiti e gli input standard dell'algoritmo ..

Sono nuovo di TDD (leggi: Probabilmente non lo sto facendo bene), ma sembra essere più adatto ad algoritmi facilmente descrivibili, quando si può facilmente ragionare su quali input corrispondono a quali output.

Quando sto facendo di più "Non so quale sarà il risultato" TDD non mi è stato molto utile. Quello che faccio invece, io uso asserzioni molto generosamente su piccole porzioni, so che lavoro come dovrebbero funzionare finora. In questo modo non rimango bloccato cercando di codificare su un target che non sono sicuro che sia l'obiettivo valido, ma ottengo un po 'di protezione, localizzando le aree del dolore in porzioni più piccole del codice.

Una volta che l'algoritmo è stato corretto per correttezza (come nel caso in cui sono sicuro di almeno alcuni input - > output per il controllo spot), allora torno indietro e scrivo un test. Quindi è molto più sicuro tornare indietro e refactoring, o ottimizzare la velocità o l'utilizzo delle risorse.

Direi che questo tipo di cose è più adatto per RDD: lo sviluppo basato sulla lettura.

Qui è dove leggi in un libro l'algoritmo per qualcosa di complicato come un filtro di Kalman, e poi lo traduci in un'implementazione nel tuo ambiente di destinazione.

Lo svantaggio è che fare le cose in questo modo significa che non si ottengono casi di test gratuitamente come parte del processo di progettazione. D'altra parte, qualcosa che conosciamo come questo ha quasi certamente un'implementazione esistente (es. Maths Math ). E quindi è molto semplice utilizzarlo come oracolo di prova per la tua nuova implementazione; tutto ciò di cui ti devi preoccupare è che il tuo set di casi di test copre tutti i percorsi del tuo codice.