Test delle unità: sulle strategie facili e difficili

Vai prima per i test semplici, se non altro perché quando inizi a scrivere gli hard test, sarai in grado di fare qualche regressione per assicurarti che i tuoi refactoring non abbiano infranto nulla.

Come da tua domanda: non dovrebbe essere così a meno che il sistema sia incredibilmente altamente accoppiato. I test facili non devono costringere i refactoring a rendere più facili i test più difficili. Questo potrebbe finire per essere il caso, ma il tuo codice dovrebbe essere il più ortogonale possibile, rendendo così i tuoi test altrettanto ortogonali.

Potresti fare un caso più strong per i tuoi test di integrazione, aiutandoti a farlo.

Vorrei iniziare con i facili test delle unità prima solo per avere l'esperienza di scriverli sotto la cintura. Assicurati che i tuoi test siano approfonditi e che tu stia testando tutti i casi a cui puoi pensare per tutte le combinazioni di input alle classi / metodi che stai testando. Iniziare con la scrittura di test più difficili potrebbe scoraggiarti dal test dell'unità.

I componenti legacy con molte dipendenze saranno difficili a prescindere dal numero di componenti più semplici che fai. Il motivo è semplice, per testare devi rompere le dipendenze hard-coded senza rompere il componente dipendente. Tipicamente, il componente con molte dipendenze sta facendo un sacco di cose e mescolando queste dipendenze in modi empi. Quindi il lavoro di scomporre e testare queste dipendenze mantenendo lo stesso comportamento è molto più difficile e non sarà migliorato dai vostri sforzi su componenti più semplici.

if you start from easy tests, shouldn't you end up making hard tests easier?

Dopo aver implementato test più semplici, gli hard test diventeranno un po 'più semplici nel senso che ottieni esperienza come dichiarato da @Bernard.

tuttavia la difficoltà con gli hard test è che i moduli non sviluppati da tdd sono in genere strettamente accoppiati ed è quasi impossibile testare la funzionalità in modo isolato.

il mio consiglio:

• fai alcuni test facili per avere esperienza.
• crea test di integrazione per i casi difficili.
• non creare test unitari per i casi difficili purché tu sia un principiante tdd.
• lo sviluppo basato sui test per le nuove funzionalità per acquisire esperienza sull'implementazione con la funzionalità accoppiata liberamente