[ODE] Latest Commit

[Rodrigo Hernandez]

Well, actually, I found it to be easier for cross platform development, 
so I sticked with it, the pain was to keep updating projects and writing 
inline asm twice with VC++. :)

I really never done Unit Testing, I have some tests on my engine, but 
they are very similar to the ones already in ODE, a bunch of exe's that 
focus on a particular
parts of the code, now that Unit Testing has been brought up here, I am 
thinking about adding cppunit support to my engine, as for ODE, well, I 
am not imposing
anything, I think a "more complete" solution should be prefered over a 
"one header" solution, but if you guys think such a solution is good 
enought, I am all for it.

However, the idea that testing code would end up on the final binary 
library, either just as extra bagage or actually affecting performance 
keeps bothering me, can someone
care to explain how this will not happen?

Cheers!

Jon Watte (ODE) wrote:

>
> Congratulations, you won an award for self-punishment! Honestly, 
> though, even among indies, I'd estimate the percentage of shipping 
> games that use MinGW to... counts on thumb... :-)
>
>
> Seriously, though: In my world, unit testing is not anything optional. 
> Ideally, unit tests get run each time compilation has finished, and 
> break the compilation if the test fail. Having to download and install 
> a secondary package to get that ability seems sub-optimal. A minimal 
> framework which sits in a header seems a better choice.
>
> What I've seen work pretty well is having unit tests register their 
> factories using static construction, and a single function you call to 
> run all of the unit tests. That way, the unit tests can be built into 
> the DLL, and the "unit test runner" binary would just link against the 
> DLL, and call the magic function. Making this binary run as a 
> post-build step would be quite trivial even in MSDEV syntax (and a 
> no-brainer in Make).
>
> Cheers,
>
>             / h+
>
>
> Rodrigo Hernandez wrote:
>
>> Ouch!, and here I am, developing almost entirely on MinGW, hope my 
>> customers never find out what a phony developer I am.
>
>
>