Renderer Unit Testing

Practical and theoretical implementation discussion.
koiava
Posts: 47
Joined: Thu Apr 24, 2014 8:18 am
Location: Tbilisi, Georgia
Contact:

Renderer Unit Testing

Postby koiava » Tue May 13, 2014 7:11 am

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? :)
Colibri Renderer

friedlinguini
Posts: 82
Joined: Thu Apr 11, 2013 5:15 pm

Re: Renderer Unit Testing

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.

koiava
Posts: 47
Joined: Thu Apr 24, 2014 8:18 am
Location: Tbilisi, Georgia
Contact:

Re: Renderer Unit Testing

Postby koiava » Thu May 15, 2014 8:07 am

Thanks, answer was really helpful! :)
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 :)
I think it's really good way.
Colibri Renderer

friedlinguini
Posts: 82
Joined: Thu Apr 11, 2013 5:15 pm

Re: Renderer Unit Testing

Postby friedlinguini » Thu May 15, 2014 11:41 am

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.


Return to “General Development”

Who is online

Users browsing this forum: No registered users and 7 guests