If you have methods 'assisting', chances are your single, big method is actually doing too much. Splitting into smaller methods and then moving these methods into separate classes with public interfaces keeps the class with the big method responsible for one thing and one thing only (see Single Responsibility Principle). This move into separte classes automatically makes for a testable structure as your methods must be made public.
Take a BankAccount-class that does budget calculations by looking at a list of Expenditures it contains. An Expenditure has a category (sports, food, car,...), an amount and a date. You might have a method on BankAccount called "CalculateExpenditureFor" taking a begin and enddate and a category. That method would filter the Expenditures to only have Expenditures that match the date and category and then proceed to sum up the amounts. Take note of the amount of 'ands' I need to express that requirement! This is clear indication that your method does too much.
This method will actually do two things: filter the expenditures and sum up the amounts. Now imagine your BankAccount contains an ExpenditureLedger-class, which contains the Expenditures (a 'ledger' is a book or file containing a list of financial transactions, hence the name). You could then have a FilterExpenditures-method on the ExpenditureLedger which takes care of the filtering on date and category. The resulting list of Expenditures can then be used by the BankAccount to tally up the amounts.
In this scenario, you have a public method on the ExpenditureLedger that can be tested (you feed the ledger Expenditures and check the result). You can also check the BankAccount-method by feeding it a (preferably mocked) ExpenditureLedger so you can test the code that sums up the amounts returned by the ExpenditureLedger.