Dovremmo scrivere un test unitario per la classe che chiama un'altra classe che ha il codice scritto

In generale, sì. Il punto di un unit test per B è dimostrare che il metodo B.b () fa il suo lavoro dati i collaboratori appropriati . Se ci fosse un problema in A , dovrebbe già essere scoperto dal test di unità per A , quindi duplicare questo controllo nel test per B è uno sforzo inutile. Basta andare avanti e fornire un MockA che puoi interrogare per dimostrare che A.a() è stato, infatti, chiamato.

In pratica, per classi e metodi di piccole dimensioni può diventare più sforzo per fornire mock per ogni collaboratore piuttosto che andare avanti e testare il risultato di B.b() per correttezza. Strettamente parlando, questo non è più un test unitario perché dipende da altre classi, ma dal momento che il punto principale di mantenere i test piccoli e focalizzati è quello di salvare lo sforzo di sviluppo senza compromettere la correttezza, non vedo perché non si dovrebbe usare il già funzionalità verificata di A per scrivere un test più piccolo e più accurato per B .

In generale, dipende.

In particolare, direi che dipende dal fatto che la classe A dipendente sia incapsulato o iniettato .

Nel primo caso, stai testando "funziona B?" Nel secondo, è più possibile che B lavori, dato un A appropriato.

Questa distinzione errata, in entrambe le direzioni, è una causa abbastanza comune di test non validi, che si tratti di mock eccessivamente fragili, di duplicazione / accoppiamento test o di problemi di integrazione persi.

Alcuni direbbero "mai incapsulare", ma se li prendi sul serio, finiresti per prendere in giro titoli come RegExp e BigInteger, che non possono essere ragionevoli.

Ovviamente, si tratta di una situazione di pollo e uova, poiché il modo in cui testerai B ha almeno una certa influenza su come è stato progettato.