# Generate or precalculate expected results for component test cases?

This topic is 697 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I want to write some tests for my game,
The most important things to test are the components interfaces,
that would include the pathfinding module, physics module, IK module and avoidance module.
Take the pathfinding module, how can I work out/write down the correct expected results
so that the test module can have something to test against?
since I think I wouldn't calculate the results in advance with a pen and paper, or would I?
It's hard to get it right..
What do you think?
Thanks
Jack

##### Share on other sites

Take the pathfinding module, how can I work out/write down the correct expected results so that the test module can have something to test against? since I think I wouldn't calculate the results in advance with a pen and paper, or would I?
As you said, you need a second source of correct answers, to have something to compare against.

In general, you want to test only a small elementary part in each test. For path finding, for example, if you give a starting point and a finish, do you get a path from start to finish?

You typically check the elementary cases, like start and finish on top of each other, start and finish are neighbours, or start and finish cannot be connected.

A few cases with a few tiles distance (eg 5 tiles above each other), and a few cases where you have to avoid an obstacle.

For optimality checks, you can verify whether a path runs through some tile halfway. If it must avoid an obstacle, you can see in advance what the solution should be, and verify eg that a tile at the corner is visited.

For really simple cases, you can even see the path length in advance. For example, if my cost for a tile is 10, and the path is 2 tiles straight, the cost should be 2*10.

The advantage of the above is that you can be reasonably sure there is no error in your second set that you compare against.

Another approach is to write another program that computes the same thing in a different way. The big danger there is that you write both programs, which means you will make the same mistakes in both programs. Your test data is thus flawed in the same way as the code you are testing. As a result, it may happen that your tests succeed, but the end result is still wrong, since both implementations have your flawed assumptions.

Ideally, you want tests written by someone else, and code written by someone else. He/she will also make mistakes, but it's very unlikely that your mistakes are the same as the mistakes by that other person.

If that is not possible, write a program for expected results in the most simplistic way you can. It may need 30 minutes to compute the answer, the only thing you should worry about is that the answer is correct. For path-finding, write a different, very simplistic algorithm like breath-first (if the code you are testing doesn't do that).

If you need some optimal value, the pretty much sure-fire way to get the correct answer is to brute-force try each option. This is of course horrible in the general case, but for test cases, which are generally small, it's feasible.

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633736
• Total Posts
3013598
×