Non sono sicuro per te, ma per me i Test automatici (test delle unità se possibile) sono un buon modo per scoprire come funziona il codice e sapere che non funziona come previsto.
I test automatici sostituiscono il debugging, cambiando le conoscenze e le verifiche verificate dallo sviluppatore con memoria di riserva, in uno controllato esplicitamente da file.
Quando torni al tuo lavoro più tardi, sarai nello stesso punto dopo alcuni secondi di esecuzione dei test, invece di cercare di recuperare il tuo contesto da vecchi ricordi e di ripetere una lunga sequenza di debug (queste ultime due attività potrebbero richiedere comunicazione scritta comunque in quanto la memoria potrebbe non essere sufficiente, quindi i test automatici non avrebbero alcun sovraccarico).
Lo so, alcuni progetti non sono facilmente testabili automaticamente. Usiamo TDD per risolvere questo problema, ottenendo anche molti altri vantaggi ....
Se scrivi già alcuni test automatici, gli stessi test che scrivi scrivono automaticamente ciò che stai pensando e verificando, quindi probabilmente non hai bisogno di nient'altro . Quando finalmente trovi il tuo bug, puoi mantenere la tua sequenza di test ... o rifattarla; -)
Modifica dopo commento:
Verifica come funziona una libreria! Io chiamo quel test di apprendimento.
Bene che tu li faccia:
- ti permettono di sapere esattamente come funziona la libreria.
- documentano tale conoscenza, per te in seguito o per i membri del tuo team
- possono documentare gli usi di quella libreria, come è usata nel tuo progetto
(nelle mie esperienze di Aeronautica, la politica aziendale ha imposto che ogni codice esterno sia controllato, sapendo con precisione quali funzioni vengono utilizzate e documentando quale sarebbe l'effetto sul nostro software se la libreria smettesse di funzionare!)
- servono come test di non regressione quando si aggiorna la libreria