How to test functions which has a return value that takes manual effort to calculate - unit-testing

Question

Assume we have the following pseudo-code:
class Position{
int x, y
}
class Body{
Body parent;
Position start; //always initialized relative to parent's
}
class OrbitingBody extends Body{
int angularVelocity; // angles travelled per day
int radius; // radius of the orbit, like earths orbit radius around sun
//returns its position after 'days' days relative to its parent
Position getRelativePosition(int days) {
totalAngles = self.angularVelocity * days
roundedAngle = totalAngles % 360
return Math.polar2Cartesian(roundedAngle, self.radius)
}
// returns position relative to the absolute parent, i.e Sun
Position getAbsolutePosition(int days) {
position = self.getRelativePosition(days)
if (self.parent) {
parentPosition = parent.getAbsolutePosition(d)
// Math.relativePosition converts position with respect to parents'
position = Math.relativePosition(position, parentPosition)
}
return position
}
}
class Sun extends Body{
// position will be (0,0)
}
class Planet extends OrbitingBody{
//parent will be Sun
}
class Moon extends OrbitingBody{
//parent will be a Planet
}
The above classes describe a basic modal of our solar system.
The method getAbsolutePosition finds position of the moon with respect to sun. For a planet this is straight forward.
For moon, there is a complication, as it returns the position relative to sun. getRelativePosition will always return relative to its parent, i.e for moon it will return w.r.t earth.
My objective here is to unit test the getAbsolutePosition.
If I have to test this for moon, I have to find out the return values that requires quite some manual effort, for a bunch of test cases. If there is any change in math logic, that would mean I have to find the updated return values again manually.
What are good software engineering practices to test functions like these?

Answer 1

You are correct in your assumption that tests which require "heavy computational work" in order to determine the "expected" values to check your actual results against would really suffer if base assumptions change and the expected results would change as result of that.
I see one option here: if possible, simply compute the expected test results, too, but don't code that yourself. You see, if you create test code and production code, chances are that you could make the same mistakes twice. So even when you would try to implement the required equations "in a different way" you doing test and production code isn't exactly ideal.
Thus: if possible, find somebody else who puts down computational logic to be used within your test cases. Maybe that code be somehow simplified - those "generators" don't need to be perfect; but they should give correct results for those corners you will be using them.

Answer 2

I often resolve these situations by writing implementation first, then using it to calculate values for test inputs, then I only verify them by hand, which is usually tiny bit easier than calculating them completely (although there's risk of introducing some bug into expected values from bug in code, I my verification fails).
Sometimes to get at least some distinction from the implementation code I do the math in Libre Office calc sheet, so I'm using the same formulas, but written second time by me, and into cells, so I usually end with a bit different structure and make sure one more time, that the formulas are as I wanted them.
Also try to decouple the complex calculations into several simpler steps, so you can mostly unit test the simple operations, then treat the whole operation more like integration test, testing only few cases. In case the internal logic will be adjusted, it will maybe break all those complex tests, but the simple operations tests will work for those which didn't change.
If this would be some real world astrology (it looks like 2D simplified space model, probably for some interactive animation), you would be maybe able to find some example data already computed by others, in some book/etc, so you could use those, that helps a lot (especially to find bugs in calculations of others :)).
And if you don't need super accurate results, but you just need to know that Moon was on Earth orbit and toward Sun, then you can test results against expected values guessed by hand with some big margin for error (like 1/4 of orbit distance, etc).