Help Unit Testing cascading calculations -

i have class used part of financial application. class bound ui form , accepts handful of values used calculate financial data. calculated values presented properties on object. several of these calculations use other calculations.

for example, calculationa may return propertya + propertyb. calculationb returns propertyc - calculationa. (this extreme over-simplification).

i trying write unit tests make sure these calculations performed correctly , wondering approach should taking.

my first approach manually recalculate expected result in test method. example, when testing calculationb, populate test object set expected result equal propertyc - propertya + propertyb. since real object has 25 properties involved, quite cumbersome.

on option thought of create test object, populate values write test verifies calculationa equals propertya + propertyb , test verifies calculationb equals propertyc - calculationb. latter assumes calculationb correct, matter purpose of unit test?

what guidance/suggestions can make setting tests accurate, reliable , maintainable? best way ensure calculations correct , didn't accidentally set calculationb = propertyb - calculationa, instance.

your case sounds equivalent spreadsheet, , spreadsheet unusual syntax code of form:

f1(f2(a, f3(b)), c); 

where f1-3 calculations, , a-c input properties. 'chaining' fact outputs of functions used inputs others.

this kind of functional calculation code unit testing shines. testing assembly whole means change specification of f3 change test cases f2 , f1 in complicated meaningless way. result in cutting , pasting calculation result test expected result. kind of makes whole exercise little pointless.

so if minimal set of test cases like:

f1(7, -2) => 23 f2(1, 2) => 7 f3(4) => 5 

then can implement each of test cases by:

1. set properties fixed large numbers
2. set input properties input case
3. check output property

because point 1 shared between tests, effort produce test cases each calculation proportional complexity of specific calculation, not total number of properties.