At 3/7/13 04:39 PM, Rustygames wrote:
The drive for unit testing at my work has increased massively, I've not done it as a rule for every project so I'm not that experienced with it. When you say you unit test everything, do you just mean the business logic behind the code? Because I'm not entirely sure what would even be unit testable in such a graphically rich application (such as a game). Could you give some examples of what you would apply unit tests to?
well, I don't generally have just one test I run through my entire game. While i'm building functions, I test out different oddball parameters that can go into it or use different variables it takes from the class. Then I stress-test and optimize some. After the class is done, I put it in some real-world scenarios and then stress-test with some extreme scenarios. I try to put in anything I think could possibly break it or spit out weird shit. Throughout the process of creating a small class i'll have run it roughly 20 times, depending.
Once a state is finished, I run it and click ALL the things.
I apply unit tests to anything I can. If it takes input in any form, i'll change to make sure it doesn't break or do something weird later on. Sometimes testing means throwing in different parameters, and sometimes it means letting it run for a few minutes, cycling as fast as it can without crashing.
As an example, I developed a file for generating pseudo-random numbers. I stress-tested the seed values as well as let it run at top speed for several minutes, trying to find duplicates or seeing if it crashes when not finding an unused number.
Turns out, inifnity's pretty big, so I didn't have to worry about crashes.