I've been working quite hard lately to overhaul my library's test driver. I hadn't updated that part of the library since back in june 2012 or so and so as predicted it was in an advanced state of decay, completely out of sync with the new coding style guidelines and other stuff. Anyway, I have revived it. It's proved to be a long and tedious process, mostly because there is so much stuff to test and the code is rather boilerplate.
I also wrapped the unit testing back-end into a nice graphical interface. This was partly because I needed eye-candy to look at while working, but I can rationalize it by claiming it makes scanning the output easier (it's hard to differentiate "PASS" and "FAIL" at a glance in white, fixed-font letters). So now passing tests show up in soothing green, and failing tests are displayed in threatening red. Wow, who would've thought of that?
This is what I have so far:
It's not much, but it's a start. The old program had 63 test vectors (grouped under 6 main categories) which covered most of the code pretty well, but incidentally did not test much of the rest of the library's features (which are going to become important once I start cross-compiling this onto every platform in sight, since I won't have the luxury of doing testing directly on the targeted hardware). In fact I uncovered a couple bugs while implementing additional tests, one minor and one rather major but which hadn't come up in testing due to.. well.. crappy unit tests that'll teach me.
I actually wrote a Python script to convert my old "text-based test vector format" into the "new" format (a static array of structures directly embedded into the code). This makes things a lot simpler, especially since I no longer depend on an external file, so no need to parse it and handle any errors. And it's not like rebuilding is difficult, either, if you're developing tests you're supposed to be able to compile
The C unit testing "framework" was also pretty simple, really just an array of function pointers which each tested one part of the library, and returned success via an integer return value (they were also provided a char buffer to report any additional information, and a FILE* to dump really detailed debugging information into).
There is just so much stuff to do though, the sheer amount of code to test, audit, maintain, and upgrade often seems overwhelming. But I'll get there eventually
--
In other news, Ordo is now working under Windows (both 32-bit and 64-bit), all Linux flavours under x86 and x86_64, and all BSD variants under the same architectures. Supported compilers are gcc, mingw, and clang (I think I'm going to only support those - supporting multiple compilers simultaneously is a pain, especially since MSVC seems to have alternative definitions for literally everything)
I have also been reluctantly forced to at least partially drop C89 support. It turns out stdint.h is actually a C99 header, which means it's basically impossible to write portable, strictly standard C89 code without a crapload of #ifdef's to essentially reimplement the missing headers oneself, which I am not ready to do at this time. Perhaps later I'll switch to an "arch folder" design, but for now this is how things are.. ah, you gotta love C with unhelpful standards and endless pedantry..
--
Anyway, my work here is done for tonight - the old tests have been 100% ported to the new testing software, now I only need to clean everything up