Ho trovato quando sviluppavo il codice di ricerca (algoritmi di grafi e algebra lineare sparsa per il lavoro di laurea e in un laboratorio di ricerca aziendale), i test unitari finiscono per essere inestimabili.
Quando il tuo algoritmo ha prestazioni peggiori del previsto, devi essere in grado di determinare con certezza che si tratta di un problema con l'algoritmo e non l'implementazione . Se non lo fai, potresti finire di scartare una ricerca promettente o pubblicare risultati errati.
Lo sviluppo orientato ai test prevede specifiche continuamente mutevoli e incomplete. Assicurandoti che il tuo codice funzioni a livelli bassi, puoi riorganizzarlo, cambiarlo e riutilizzarlo. Ho visto molti studenti laureati buttare via molti mesi di lavoro perché hanno cercato di risparmiare tempo non verificando che il loro codice funzioni.
Ogni volta che identifichi una funzione che vuoi scrivere con un comportamento definito (ad es., norm2() , calculateHitRate() , calculateResidual , ecc.), scrivi un test unitario per questo. Alcuni dei vostri test unitari possono essere sotto forma di controlli di sanità mentale piuttosto che di validazione dell'output reale, ad esempio per garantire che una matrice sia definita simmetrica o semi-positiva. Fondamentalmente assicurati in ogni fase dell'algoritmo, che i tuoi dati abbiano le proprietà che ti aspetti. Ricorda che in TDD, scrivere il codice minimo per passare il test non implica scrivere codice errato che supera il test, ma piuttosto non scrivere funzionalità che non sono testate.
Nella ricerca, ritengo che i test di accettazione automatizzati abbiano un valore molto inferiore, poiché in molti casi eseguirai un'analisi qualitativa dei risultati (capendo perché il tuo algoritmo si è rivelato peggiore o migliore). Se il tuo algoritmo si traduce in un tasso di successo di 0,21 anziché di 0,24, come saprai che è dovuto a un bug, o solo che il tuo algoritmo non è così buono su quel set di dati come speravi?
