How to unit test code with very few units

Question

How can I write unit tests for existing and already implemented code which has taken a procedural implementation as opposed to an OOP implementation. We are using Java/Spring, however there are not a lot of different beans for the different concerns, which are all mixed into one large class per piece of of major functionality. (EG: we have classes/beans for each batch job, for our DAOs and a few util type beans and that's it).

Just to give some more details, these major classes which need to be tested are about 1k-2k lines of code, and the only dependency injection/OOP they use is DAOs and some odd utilities. They have about 1 public method which they implement for an interface they all share.

Answer 1

Start by refactoring. Modern IDEs will allow you to refactor safely without breaking or changing the code semantics. But you have to do this consciously and be smart.

Start from "outer" classes that are not dependencies of any other classes.

First step is to extract as many methods as you can. Typically when you find a huge method with lots of blank lines/comments separating blocks of code they are good candidates for extractions. Also loops, nested conditionals, long switches, etc. should be considered.

Once you have plethora of well named methods look around and try to group them by moving them up and down. If some method are closely coupled and logically dependent, extract them to a separate class. IDE will assist you.

This process can be repeated on every layer and multiple times. Aim for small, cohesive classes, if you cannot name it (e.g. you have to use "And" to express what method/class is doing), extract further.

Of course you can test it as-is - I guess every possible execution path can be reached with different set of input parameters. But this will be a nightmare to debug.