There is no general recipe, but some rules of thumb
(supposing a statically typed language but that shouldn't really matter):
1) Take a look a the method signature. It tells you what goes in and hopefully comes out. From the overall state of this god-class, I suppose this to be a first pain point. I suppose, that more than one parameter is used.
2) Use the search function from your Editor / EDI to determine Exit-Points (usually a return statement_ is used)
From that you know, what the function needs for testing and what you expect in return.
So a simple first test would be calling the function with necessary parameters and expect that the result is non-null. That is not much, but a starting point.
From that you could enter a hermeneutic circle (a term coined by H.G. Gadamer - a german philosopher). The point is: you have now a rudimentary understanding of the class and update this understanding with new detail knowledge and have a new understanding of the whole class.
This combined with the scientific method: make assumptions and look if they hold.
3) Take one parameter and look, where in the class it is somehow transformed:
E.g. you are doing Java like me, there are usually getter and setter for which you can look. Searchpattern
$objectname\.(get|set) if you are doing Java)
You could now make further assumptions on what the method does.
Trace only the input parameters (first) each through the method. If necessary make some diagrams or tables, where you write down every change to each of the variables.
From that, you can write further tests, describing the behaviour of the method.
If you have a rough understanding how each input parameter is transformed along the method, start experimenting: pass in null for one parameter or strange input. Make assumptions, check the outcome and vary input and assumptions.
If you do this a time, you have a "ton" of tests describing the behaviour of your method.
4) In a next step I would look for dependencies: what does the method need besides its input to work properly? Are there possibilities to reduce or restructure those?
The less dependencies you have, you clearer see the points, where to make the first splits.
5) From there you could go down the whole refactoring road with refactoring patterns and refactoring to patterns.
Here a nice Vid: GoGaRuCo 2014- The Scientific Method of Troubleshooting It's about troubleshooting but nevertheless usefull for a general methodology of understanding how something works.
You mention, that the called function has no input parameters: In this special case i would try to first identify the dependencies and refactor them to parameters, so you could swap them in and out as you like.