Renderer Unit Testing back

(L) [2014/05/13] [tby koiava] [Renderer Unit Testing] Wayback!

I'm interested to cover my code with tests, but some parts isn't clear.
Assume I have some function getCosineWeightedRandomDirection which generates vectors randomly and I know that in infinity it will be distributed as desired.
How I can test this function, to ensure that it's not correlated?
If I'll call this function in 1000 times and check if outcome is as desired(with some error), does it gives me a guarantee?
I'm also interested how many of you uses testing framework in this type of projects? [SMILEY :)]

(L) [2014/05/14] [tby friedlinguini] [Renderer Unit Testing] Wayback!

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.

(L) [2014/05/15] [tby koiava] [Renderer Unit Testing] Wayback!

Thanks, answer was really helpful! [SMILEY :)]
In this case Injection of sample generator would be solution.
End of every month project becomes unstable and finally I decided to cover with tests [SMILEY :)]
I think it's really good way.

(L) [2014/05/15] [tby friedlinguini] [Renderer Unit Testing] Wayback!

If test coverage is important to you, I suggest Googling "test-driven development" if you haven't looked into it already. If you're going to do the work of writing tests anyway you might as well minimize debugging time, plus code that is written to be testable tends to be well-factored as well.