Sento molto spesso quanto segue: "Se vuoi testare metodi privati, è meglio metterlo in un'altra classe ed esporlo."
Anche se a volte è così e abbiamo un concetto nascosto nella nostra classe, altre volte si finisce con classi che hanno gli stessi attributi (o, peggio, ogni attributo di una classe diventa un argomento su un metodo nell'altra classe ) ed espone funzionalità che sono, in effetti, dettagli di implementazione.
Specialmente su TDD, quando refactate una classe con metodi pubblici da una precedente classe testata, quella classe ora fa parte dell'interfaccia, ma non ha test (dato che l'hai rifatta, ed è un dettaglio di implementazione).
Ora, potrei non trovare una risposta più ovvia, ma se la mia risposta è "corretta", ciò significa che a volte i test di unità di scrittura possono interrompere l'incapsulamento e dividere la stessa responsabilità in classi diverse.
Un semplice esempio potrebbe testare un metodo setter quando un getter non è effettivamente necessario per qualcosa nel codice reale.
Per favore, quando non si forniscono risposte semplici a casi specifici che potrei aver scritto. Piuttosto, cerca di spiegare più del caso generico e dell'approccio teorico. E questo non è specifico per la lingua.
Grazie in anticipo.
EDIT: la risposta fornita da Matthew Flynn è stata davvero perspicace, ma non ha risposto alla domanda. Anche se ha fatto il punto giusto di non testare metodi privati o di estrapolarli perché in realtà sono altre preoccupazioni e responsabilità (o almeno questo era ciò che ho potuto capire dalla sua risposta), penso che ci siano situazioni in cui i test unitari sono privati i metodi sono utili Il mio esempio principale è quando si ha una classe che ha una responsabilità ma l'output (o input) che dà (prende) è solo complesso. Ad esempio, una funzione di hashing. Non c'è un buon modo per rompere una funzione di hashing e mantenere la coesione e l'incapsulamento. Tuttavia, testare una funzione di hashing può essere davvero difficile, dal momento che è necessario calcolare a mano (non è possibile utilizzare il calcolo del codice per verificare il calcolo del codice!) L'hashing e testare più casi in cui l'hash cambia. In questo modo (e questa potrebbe essere una domanda che vale il suo stesso argomento), penso che il metodo di test privato sia il modo migliore per gestirlo. Ora, non sono sicuro se dovrei fare un'altra domanda, o chiedere qui, ma c'è un modo migliore per testare un output così complesso (input)?
OBS: Per favore, se pensi che dovrei fare un'altra domanda su quell'argomento, lascia un commento. :)
EDIT2: Ho accettato una risposta come mia corretta perché mi ha fatto pensare e decidere la mia linea d'azione, anche se non ha risposto completamente alla mia ricerca. Ma per quelli che affrontano lo stesso problema di me (una classe coesiva che cambierà insieme, ma è ancora troppo difficile da testare da sola), dirò cosa ho fatto e perché. Ho deciso che l'output di quella classe è semplicemente troppo difficile da testare su un computer, quindi non l'ho testato. Avrei potuto usare un framework per testare i suoi metodi privati (che sarebbe la migliore idea, penso), ma non volevo arrivare a quel punto. Se ti stai chiedendo cosa sia coesivo e rispetti SRP, ed è ancora troppo difficile da testare su un computer, darò alcuni esempi: generazione di heightmap, funzioni di hash, generazione di musica procedurale (puoi testare alcune unità, ma l'unità di livello più alto è semplicemente troppo soggettiva).