Postby friedlinguini » Wed May 14, 2014 12:52 am
What is your goal here? Test coverage is nice, but I'm not sure how helpful it is to run simulations on what's generally a relatively trivial function. You do get some benefit with test-driven development, but the primary benefit is in design, with test coverage being a nice side-effect. In fact, from a TDD standpoint, the fact that you're having problems deciding how to test the function shows that it's not very testable in its current form. Treat that as a cue to reexamine the design.
A better approach would be to write getCosineWeightedDirection (minus the "Random") to either take a random number generator as input, or maybe just a pair of floats. This gives you a chance to verify that a particular set of "random" numbers generates the desired output direction. If you don't have confidence in the algorithm, you could force the input to stratify over a range of possible inputs, which will give you much better-behaved results than simply running a monte carlo simulation that is not guaranteed to give an accurate answer every time. This is not necessarily the sort of thing that you want to run as part of a suite of unit tests, since a large number of such tests covering an entire rendering system would probably take some time.
As a side effect, this lets you decouple the random number generation from the algorithm for generating cosine-distributed directions, which can be helpful if you want to switch to quasi-monte carlo methods or primary sample space MLT.
