After you have possibly made a bit of a mess of your code because you are trying to make it pass the test you just made. And now it passes. And you are ready to check in the code. Check it in because it works. But then go back and look at your code and see if you can refactor and make it clearer. ( e.g. see if those accessors are actually needed. etc )

The same goes for tests. For me, my tests usually get the most messy. Making test objects, making test data, making “correct data” / mock objects of systems to run against, check various conditions, checking boundary cases, etc. Refactoring those is a necessity.

But once you have them. Oh so sweet. No longer do you fear making significant changes to the code. And when other people need to add something or fix something in the code you wrote. Boom just run the unit tests and see if they still work. No more “oh I changed the defaults for how some data is loaded and now the mobs in the game don’t move.”

For me, one key insight for using TDD was: Okie I have to make this object. It has a bunch of requirements. When I am coding that object I am either using the debugger to test out those requirements or I am writing the object and then loading up the game and testing all of the requirements in the game. So maybe I spend maybe 2x as much time up front writing tests compared to loading up the game and testing. (that time goes down once writing unit test becomes second nature). But now when an issue arises I can run the tests and quickly say: “well the code is working let’s look at the data.” (NOTE: TDD purists will say TDD helps you “explore” the solution space or what not. Yes it does, but if you are going to code something you have to have some user story or requirements or idea of what you are making. TDD doesn’t really help with that part. Once you have that part you can start doing TDD.)

Also with tests you have a nice way to check individual components easily. Example: some texture or game object is causing a crash or is not being loaded correctly or the behavior is wrong. Usually you load up some test level, find that object, load it up and then try to debug what is going wrong (in some cases many steps are involved to place only that object). With TDD there should be a test somewhere where you can point to the offender instead of the mock object you were using before and have a small working set to debug. And if there is not, well time to make one!

Also another key insight for me was: you don’t need to test EVERYTHING. That way lies pure madness. When you are writing an object you can probably guess / know which parts are going to be “tricky” / “open to errors”. So test those. (i.e. replace debugger time with test writing time to make certain you coded it correctly) Don’t fret over not testing whether or not the the setName( const std::string& p_newName ) actually set the name when the code for that is something like:

void SomeNamespace::SomeClass::setName( const std::string& p_newName )

{

    m_impl->name = p_newName;

}

I think _PURE TDD_ would require that a test be written, have it fail, then go write the above and smile when it worked. And for some of the crazy string classes out there you maybe would want to actually test that! But to me that is going to be in the 20% in the 80/20 rule of what needs to be tested. Of course if this manages to fail at some point, a test shall be created with all due haste!

But something like:

std::string getFullName() const;

    // returns the full name of the player. First and last name are capitalized and the title is prepended to the name iff there is a title. Additionally the guild affiliation is attached to the end also.

    // NOTE: we probably don’t want the guild name included in this but that is what design wants at this time.

That probably gets some tests where you have you test all of the conditions.

ahh part 3 is up it seems and this comment will be lost forever! haha

Games from Within is a weblog written by Noel Llopis,

who has a pretty impressive game d…

The stunningly wonderful thing about TDD is that you often end up with code that is far simpler than you previously envisioned.

TDD has helped me discover algorithms, has helped me learn how to be a better programmer, and has shown me bugs in middleware. I’ve been sold on it for a while…

Good luck, though. It’s a bit tricky to get into for a number of reasons, not the least of which is feeling less productive at first. This feeling soon goes away, and is replaced by the complementary feeling that you’re on a tightrope without a net if you’re “required” to work without tests…

However.. After reading this article I’ll be a sport and give it another go (5th times a charm?). Maybe with my previous attempts I have just missed something. I totally “get” why TDD could be so awesome. I just have not been able to achieve enough “awesomeness” to compromise/modify my programming morals.