Anonymous Answer

There are a few key principles to keep in mind while refactoring a class for unit-testing. One of those key principles is to make sure that no single function is doing too much. If you have a single function that is thousands of lines of code, then that function is doing too much and unit tests for that function are going to quickly become ugly and unmanageable. I would evaluate the function, see what responsibilities it is currently assuming, and see how those can be broken out into smaller and more manageable functions with their own set of expectations that easily translate to simpler unit tests. That same approach can also be applied to the class itself and it may be that the class needs to be split into multiple classes.

Another key principle when refactoring is making sure the refactor is more readable than the current code is. If you're going to abstract the class by splitting it out into multiple classes, it's important to balance the amount of abstraction you plan on doing and not overcomplicate or oversimplify something. You can easily abstract any single class and break it out into a series of classes and interfaces that extend other classes and interfaces which in turn extend more classes and more interfaces and you eventually end up with a web of dependencies that is more confusing than it is helpful.