Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    195
  • comments
    198
  • views
    104375

Listening to: Orff-Fortuna imperatrix mundi

Sign in to follow this  
SiCrane

97 views

Not much to report, progress-wise. I wired in the basics of the testing framework today. The testing framework is scavenged from an old project of mine. It's a XUnit style system, though much of the elegance of, say, JUnit is replaced with brute force hackery. C++ doesn't support reflection natively, which makes things interesting. From what I can tell it's fairly similar to unit++, though, as far as I know, unit++ didn't exist at the time that I started the original version. I guess it's a case of convergent evolution.

I do that a lot, incidently. For example, I've duplicated good chunks of boost without realizing it several times. Most recently, boost::transform_iterator. I've redone boost::array more times than I care to admit. (In my defense, boost::array is fairly trivial, so sometimes I don't realize I've done it until it's sitting on my screen.)

One thing I'm glad of is taking the time to run all the code through both MSVC 7.1 and gcc 3.3.1 simultaneously instead of my usual approach of coding a library in MSVC and then trying to shoehorn it into gcc.

In any case, the test system works pretty simply. You define a test class derived from a base test class in an anonymous namespace, create a static object that registers it with a the testing subsystem, and then after the entry point, you can invoke the testing subsystem to run all the tests. Some preprocessor trickery is used so that asserts in user code don't bring down the whole executable, but instead throw an exception. This is useful for automated build testing. It won't stop, for example, a memory assertion in the debug heap from bringing the whole thing crashing down, but generally, that kind of code would be caught before it got checked in. At least I hope.

One thing I forgot to mention yesterday was that part of the scaffolding I installed was a set of debug level macros. Basically every module, class and function has a priority associated with it. If the combinations of priorities in a given build aren't high enough, asserts don't fire in that function, which cuts down on runtime performance penalties.

So now that's all put down, tommorrow I can actually start working on the library proper.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!