La codifica e il test delle unità violano il principio DRY

Stai operando su una premessa difettosa.

Il codice non è una descrizione del comportamento previsto, sono solo i requisiti e i casi di test. E anche allora, i requisiti e i test definiscono due aspetti del comportamento. I requisiti definiscono le caratteristiche e le funzionalità del sistema software nel suo complesso e il test definisce quali dovrebbero essere i risultati attesi e corrisponde ai requisiti. Il codice è un'interpretazione da parte degli sviluppatori di tali requisiti e dell'architettura del sistema.

No, non viola il principio DRY perché i test unitari non riproducono la funzionalità, si limitano a garantire che la funzionalità (ri: responsabilità) funzioni correttamente. Nel caso di un test unitario, il metodo che stai testato mantiene ancora authoritative representation . Il tuo codice di prova può sembrare molto simile al codice che implementa il metodo nella versione di produzione, ma ha il suo scopo non ambiguo (per affermare il test).

However when writing tests for code you are describing the expected behavior for the system twice (once in the code and once in the test).

Non proprio. Il codice non è la descrizione del comportamento previsto, ma la sua implementazione . Che può contenere errori, ecco perché abbiamo bisogno dei test.

Implementare anche un algoritmo o astrazione abbastanza semplice è molto più complicato che descriverlo. Qualsiasi programmatore decente può descrivere in poche frasi come funziona la ricerca binaria - tuttavia, Jon Bentley ha riferito che nei suoi esperimenti, oltre il 70% dei programmatori esperti che partecipavano al suo corso non è riuscito a implementarlo correttamente.

Questo è il motivo per cui abbiamo bisogno di test unitari. A nessuno piace lavorare il doppio per ottenere gli stessi risultati, ma tutti quegli sviluppatori che hanno formulato ed evangelizzato questa pratica si sono resi conto dalla loro esperienza, duramente meritata, di averne bisogno. Erano persone intelligenti che volevano sviluppare software il più velocemente possibile, il che richiede la rimozione di tutte le faccende duplicate e inutili dal processo di sviluppo. I test unitari non sono un lavoro duplicato.

Tipo di. Se sono troppo simili, allora sì, è una brutta cosa. Il tuo test non dovrebbe essere codificato allo stesso modo del codice che sta testando. Quindi dovresti definire (1) un'aspettativa e (2) un'implementazione.

Mi piace pensare che sia simile a contabilità a partita doppia . Un sistema di contabilità fa sempre almeno 2 voci (un debito e un credito). Questa è una misura di controllo degli errori. Alla fine della giornata, i debiti e i crediti devono essere bilanciati, oppure c'è stato un errore. Non puoi avere un sistema di rilevamento degli errori senza alcuna forma di ridondanza.

Considerare un CRC per esempio. Il tuo byte CRC è una forma di ridondanza. È sufficiente rilevare qualsiasi piccolo errore nel segnale. Allo stesso modo, i CD audio hanno molte informazioni ridondanti, quindi suonano ancora perfettamente se sono graffiate. Ciò viola il principio ASCIUTTO? Probabilmente, ma è così che ottieni affidabilità.

C'è un altro modo per vederlo anche:

Il tuo test è la risposta autorevole. Il codice che prova è solo auto-generato da te, il codice scimmia. Se potessimo eseguire la generazione automatica del codice in base a test di unità (come se auto-generassimo livelli di accesso ai dati basati su uno schema di database), non violeremmo il principio DRY (o almeno non il principio OAOO).