13

Which combination of testing tools do you feel is best? Given the framework / library of your choice you might consider:

Note: While this is potentially a generic question like the one on SO I would argue that game development is usually bound to a specific work flow which influences the choice for testing. For a higher-level perspective, see question Automated testing of games.

Community
  • 1
jmp97
  • 979
  • 1
  • 11
  • 18
  • While I don't directly see anything wrong with this question, I think it would benefit from being made Community Wiki. For example: http://gamedev.stackexchange.com/questions/480/version-control-for-game-development-issues-and-solutions – Jesse Dorsey Aug 13 '10 at 19:15
  • I made it CW. However, I think the guidelines on when to make a question CW seem a bit unclear to me as a newcomer, especially since this is debated in general (http://meta.stackexchange.com/questions/55888). Maybe we could explicitly state the gamedev policy concerning this in the FAQ? – jmp97 Aug 13 '10 at 21:10

8 Answers8

7

I found UnitTest++ to be very easy to work with. I will yet have to try amop alongside with it, which was mentioned to be a good companion to UnitTest++ for mock object functionality. Otherwise Google Mock is a popular choice. Also, you may want to read up on UnitTest++ and Mock Objects.

UnitTest++ can be set up with your Continuous Integration approach, e.g. with Hudson

You may want to read this inspiring post if you're not convinced unit testing and games go well together.

Community
  • 1
jmp97
  • 979
  • 1
  • 11
  • 18
  • UnitTest++ is the only testing framework that you should need, especially given that it's easy to modify and extend. If you find yourself doing any Java programming later, JUnit will strike you over and over in the face with a hammer with the utter inelegance that it displays. – dash-tom-bang Aug 19 '10 at 00:22
  • For UnitTest++ go to github.com/unittest-cpp/unittest-cpp. Everything else is out of date. – Markus Sep 17 '13 at 11:15
4

Another vote for UnitTest++. Very easy to integrate, compiled for our target embedded platform very easily, straightforward and easy-to-use. We have also integrated it with Hudson. We looked at GoogleTest but rejected it (I think it had issues compiling for our target platform) but it has a similar feature set and might be suitable for you.

Additionally you might want to look into some kind of smoke testing framework. In my experience it is difficult to get sufficient test coverage for a game with unit tests alone. Especially if you are introducing unit testing to an existing codebase, and even moreso for a large team. Smoke testing would be testing high-level things like "make sure all the levels load". My theory is that if I have both kinds of testing then at some point they might meet in the middle and give decent converage. :)

Chris Howe
  • 516
  • 4
  • 7
2

Back when I was working in C++ (disclaimer: this was about 2005), I used a slightly modified version of TUT (Template Unit Test Framework). I liked it because it was so lightweight, which made it easy to modify, and meant there was very little "glue" required when writing tests.

Here is one very simple modification I made, that makes it even eaiser/cleaner to write tests:

static int BogusFunction() { return __COUNTER__; } // Increment the __COUNTER__ to the correct position for the begining of the tests
#define TEST template<> template<> void object::test<__COUNTER__>()
#define ENSURE(msg, cond) ensure(msg, cond, __FILE__, __LINE__)
#define ENSURE_EQUALS(msg, actual, expected) ensure_equals(msg, actual, expected, __FILE__, __LINE__)
#define ENSURE_DISTANCE(msg, actual, expected, distance) ensure_distance(msg, actual, expected, distance, __FILE__, __LINE__)
#define FAIL(msg) fail(msg, __FILE__, __LINE__)

The other change I made was to its output format, so that test failures would appear correctly in Visual Studios's error list (when run as part of a build), clickable to go to the file and line of the failed test.

(The ability to do this sort of thing means that it can be made to fit into your TDD/CI process, rather than forcing you to fit into its.)

Here is an example test (from the command-stack from my editor):

TEST // Undoing a command
{
    cs.AddCommand(new TestCommand);
    cs.AddCommand(new TestCommand(od));

    ENSURE("Undo success", cs.Undo());
    ENSURE_EQUALS("Stack size", cs.size(), 2);
    ENSURE_EQUALS("Command's Undo() was called", od.undo, 1);
    ENSURE_EQUALS("Command's Redo() not called", od.redo, 0);

    ACommandStack::const_iterator it = cs.end();
    ENSURE("Command is redoable", cs.GetUndoPos() == --it);
}

(In the above code, cs and od are per-module fixtures, and TestCommand is a mock object.)

Andrew Russell
  • 21,268
  • 7
  • 56
  • 103
2

When it comes to C++, I have tried and used the googletest framework, http://code.google.com/p/googletest/. It's simple to set up, easy to use and works great.

Simon
  • 457
  • 3
  • 9
2

I'm not a professional game developer, but I am a professional embedded developer. Perhaps not exactly like games but close. At my place of work we've used a few.

I really like google test. It has all of the best features of the recent unit test frameworks, while keeping it all in a minimal, stream lined interface.

Next on my list is Boost Test. Google test's api is a bit more modern than Boost.Test, but Boost Test has done an amazing job of adding new features and ditching the crufty CppUnit paradigm.

I've also used CxxTest. It's quite well done but you can tell that it's not as modern as either Boost.Test or Google Test. In particular, its support for test suites and fixtures is a bit awkward.

I like to use the advanced features, but if you're a minimalist you'll never see the difference between the three. Most of my colleagues would be happy with a unit test framework that supports auto registering test (in a declarative manner ) and has some sort of a CHECK_EQUALS(a,b) macro.

deft_code
  • 7,602
  • 5
  • 37
  • 54
1

My favorite testing library is QuickCheck http://en.wikipedia.org/wiki/QuickCheck. There is an experimental C++ version, but it looks too heavy weight, but even without a dedicated library the principles are easy to use.

All of my classes have a genArbitrary method that can generate a random instance. I use this for smoke testing invertible processes, like loading and unloading. I can generate thousands of random scenes and check that various properties hold (like the scene I serialize is the same as the scene I deserialize).

It doesn't replace traditional unit tests (it does reduce the need for many potential unit tests), but its a great way to discover bugs, and it helps stress test my memory allocation strategy (along with Valgrind). Its great to watch over a million allocations come out Valgrind pure :).

I used to use CxxTest as a test harness, which I liked. Now all of my tests are separate exes. I just have a folder called Test, and ever file that begins with Test_ becomes a test. So far it is a really easy lightweight to make tests.

Jonathan Fischoff
  • 1,148
  • 9
  • 14
0

With Java, there are so many good libraries... Not the case of C++.

For C++ users, there is a chain tool from Kitware that is very interesting:

  • CMake: make tool
  • CDash: continuous integration tool

Kitware writes C++ codes for Computer Science.

For personal projects, i use the Boost unit test library (on Desktop platform). For Continuous Integration, i use Hudson:

  • easy install on Tomcat
  • scriptable
Ellis
  • 3,626
  • 19
  • 28
0

I'll second the TUT (Template Unit Test) framework; it's super lightweight and extremely flexible, not to mention really easy to setup and use out of the box (a single header include, a little bit of main/setup code, and 24 lines of test code later you have a unit test). I've combined it with binfmtc (run C++ programs as scripts) for rapid prototyping/TDD/learning templates to great success, including embedded software development. Due to it being able to output to XML, it also dovetailed in nicely with Jenkins (CI) and Sonar on successive projects of mine.

Nathan Paul Simons
  • 101