Long story short I decided to add a simple logger to my engine that the core engine could write messages to as well as the game logic code. I am sticking with my desires to write unit tests for any new objects I create in the engine with the eventual goal of having the whole thing have unit tests. This time I decided to go beyond creating simple unit tests and do the full TDD approach. The full TDD approach means writing your unit test before you actually write the code. I've never really understood the major difference between doing this and just writing your unit tests afterwards until I actually did it.
Writing unit tests before hand really made me think about the functionality I wanted as an end user. Since I was calling the API before it existed I really got thinking about how I would use it instead of just throwing parameters in everywhere. All in all I really liked the approach. It's still weird to write tests that you know aren't going to compile but it works. I also got to utilize my tests right away as I decided almost at the end of coding things up that I needed to take a different approach.
When I started off I implemented all the file IO using createfile. I know this is a Windows specific API but I really didn't care about that. I was just looking for an API that I use all the time. Unfortunately I didn't really think about how crappy it is for dealing with strings. And that's all my logger is doing, passing a couple strings around. So after I had most of the functionality implemented I decided to switch back to good old fopen and fputs so I could easily handle strings and get cross platform at the same time. The good thing was that I already had a dozen or so unit tests up and running so while I was switching over I got instant feedback of what was working and what wasn't. This is what I want to have in my other systems so that when I want to switch from using DX to OGL for my Mac versions I have tests that tell me if things are working instantly.