I have a large data structure that gets read in from XML. I've been given a large list of constraints that should hold between data members. For example, one of the constraints might look likesome_complicated_function(data.childOne.fieldTwo.bar) < sqrt(        data.childThree.fieldFive.foo.quux)My best idea so far is to have tests that mock up the data in a way that fails exactly one of the constraints, and then inspect the logs. The problem with that is, everything is so inter-related that trying to arrange things so exactly one check fails -- or even tracking down all the checks that should fail from changing a 'clean' dataset in a certain way -- will take a good deal of mathematical trickery I'm not sure I'm up for.I'm thinking that since I don't have any tools to see what the output of some_complicated_function should be, I'm stuck just looking closely at my code, and the pseudocode in the reference manual where the function is described, and making sure they do the same thing by hand. Similarly, I'll have to re-write the constraint logic in order to test it, so those tests wouldn't really help my confidence that my checks work as they should.
How can I test code that verifies data sanity?
testing;validation
The way I would test this is by splitting this up into smaller units that can be tested. You haven't given any indication of what language or environment you are working in so I'll assume it's an OO-type language... The general approach might hold true for any paradigm, but YMMV.First of all: the some_complicated_function should be a method on a class. You test the implementation of the actual complicated function by passing it simple values that you control, and you validate the output. This isolates this part of the complexity by giving you one point to focus on when figuring out how the complicated function works. You test and develop it in isolation.Secondly, the interaction between some_complicated_function and sqrt should also be part of a class. The fact that this relation needs to be checked means that there is some implied significance between the fields. Make a method on this class that, again, takes two values as a simple input. Mock out the calls to some_complicated_function by passing the class we made earlier to this class and calling onto that. Test this class by passing two values, asserting that the appropriate calls to Alpha are made and that the output is correct, depending on the result of Alpha. Remember that at this point you don't care how Alpha ACTUALLY works. All you are interested in is that the result of the call should be less than the result of the sqrt call.Thirdly, have a class that you pass the XML to. This class simply calls the above class with the data that it fetches from the right fields. Testing this class simply means that you validate that a call was made to the validation method you created in step 2 and that the values from the correct fields are passed. In this test, you only care about the fact that the right fields are passed onto the method and that the validation logic behaves right depending on the result.This might lead you down a path to having loads of small methods or classes, but in my experience this drives you to cleaner code that is easy to understand because it is highly focused (and SOLID).