Unit Test: Devo fare un test unitario per ogni classe nel mio progetto

Le regole aziendali sono la cosa più importante da testare. Questi dovrebbero essere in oggetti comportamentali (oggetti che fanno cose) non in oggetti valore (getter e setter).

I test non dovrebbero mai essere eseguiti alla cieca o a memoria. Dovrebbe aiutarti a refactoring e andare veloce. Se non lo fa, qualcosa non va.

Ci sono cose che non hanno un strong bisogno di essere testate. Come le GUI che non hanno logica. Questo non significa che non puoi metterli alla prova. Ma testare un oggetto valore in un linguaggio strongmente tipizzato sta duplicando ciò che il sistema di tipi già fa per te.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Il codice nella prima categoria - "ovviamente senza mancanze" - non ha bisogno di test unitari.

Kent Beck ha offerto queste euristiche

If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

I tuoi test unitari dovrebbero normalmente essere focalizzati sui comportamenti osservabili nel tuo sistema. Quindi, il refactoring di un metodo privato in un nuovo "metodo object" non significa necessariamente che è necessario introdurre una nuova batteria di test (anche se si è invitati a farlo).