Se hai metodi di "assistenza", è probabile che il tuo unico, grande metodo stia facendo davvero troppo. La suddivisione in metodi più piccoli e lo spostamento di questi metodi in classi separate con interfacce pubbliche mantiene la classe con il grande metodo responsabile di una cosa e di una cosa sola (vedere Principio di responsabilità singola). Questo spostamento in classi separate crea automaticamente una struttura testabile in quanto i tuoi metodi devono essere resi pubblici.
Un esempio
Acquisisci una classe BankAccount che esegue calcoli di budget esaminando un elenco di spese in esso contenute. Una spesa ha una categoria (sport, cibo, auto, ...), un importo e una data. Potresti avere un metodo su BankAccount chiamato "CalculateExpenditureFor" che prende un inizio e una data e una categoria. Tale metodo filtrerebbe le spese per avere solo spese che corrispondono alla data e alla categoria e quindi procedere a sommare gli importi. Prendi nota della quantità di "ands" di cui ho bisogno per esprimere questo requisito! Questa è una chiara indicazione che il tuo metodo fa troppo.
Questo metodo farà effettivamente due cose: filtrare le spese e sommare gli importi. Ora immagina che il tuo BankAccount contenga una classe ExpenditureLedger, che contiene le spese (un "libro mastro" è un libro o un file contenente un elenco di transazioni finanziarie, da cui il nome). Potresti quindi avere un metodo FilterExpenditures su ExpenditureLedger che si occupa del filtraggio in data e categoria. L'elenco risultante di spese può quindi essere utilizzato da BankAccount per calcolare gli importi.
In questo scenario, è possibile testare un metodo pubblico su ExpenditureLedger (si alimentano le spese di contabilità generale e si controlla il risultato). Puoi anche controllare il metodo BankAccount inserendo un ExpenditureLedger (preferibilmente preso in giro) in modo da poter testare il codice che riassume gli importi restituiti da ExpenditureLedger.