TDD, weeks later

Working on the prototype has taken every disposable minute - so I haven't been blogging.  It is now much less buggy - it will run for hours and hours before an assertion fires, and the AIs usually have a reason for doing the crazy things they do - but it doesn't do much more than it did a few weeks ago.  But I am writing features again.  Yay.
It's still too early for me to tell if it feels like TDD is a win. 
Pros:
* it's very satisfying.  Writing the test before I make a change, seeing the test fail, and then seeing the test succeed, is like a drug.
* using tests to reproduce bugs is often easier and quicker than trying to reproduce bugs in the wild.
* I did a fairly massive refactoring, reversing a really stupid technical design decision I made on day one.  The old Jamie would either never have bothered out of fear, or would have done it one gung-ho attack and then spent the next few days finding and fixing (most of) the bugs I'd introduced.  The new TDD Jamie had the courage to do it, and did the refactoring one bit at a time, testing the changes as I went, and the program was less buggy when I was done. 
* TDD seems very well suited to gameplay and AI programming.  It's hard to TDD graphics and sound, but in the virtual world that the graphics and sound are just a representation of it's a good fit.
* TDD is forcing me to pay more attention to the code, and I've actually found bugs just from studying it.
Cons:
* It's a hard habit to get into.  Many times I'd jump in and start writing the code, have to stop myself, undo the changes temporarily, write the test, see the test fail, and then go back and redo the changes.  Sometimes I let myself slide.
* Hard to tell just how many tests to write.  You could write tests forever, checking every weird boundary case, entire tables of inputs and outputs, and on and on.  Or you could write no tests at all.  Somewhere between zero and infinity is the right amount, but where?
* Five minute fixes take a half hour.  I'm slower in general.
* I'm up to forty "tests" and hundreds of "CHECK" statements, and still haven't had that rewarding feeling of a test failing because I inadvertently broke something.  I've had lots of tests fail because of incorrectly written or arranged tests, though - part of what's making me slower.  On the other hand, I'm the only guy working on this:  in a multiple coder environment, it's fairly likely that guys could break each other's stuff, and then the tests would fire.

Bottom line:  still doing it.

Comments

[Hugh "Nomad" Hancock]

Whilst there's not a obvious correlation between this and Machinima work (although I have this nagging feeling there's a non-obvious one), I'm still finding your thoughts on the subject fascinating. Please do keep blogging your progress with TDD games design.

[Noel Llopis]

> [TDD] is like a drug

That says everything. You've finally gotten what TDD is all about :-)

Seriously, it's great to see you're enjoying it and it's effective. One comment based on personal experience:
> I'm up to forty "tests" and hundreds of "CHECK" statements

I would recommend to try to keep tests small and limited to a single CHECK statement (unless you're testing two obvious consequences of a single action). But certainly avoid doing action, CHECK, action, CHECK. It takes nothing to set them up as two separate tests and it'll be a lot clearer when one of them breaks.

Also:
> Hard to tell just how many tests to write. You could write tests forever, checking every weird boundary
> case, entire tables of inputs and outputs, and on and on. Or you could write no tests at all.
> Somewhere between zero and infinity is the right amount, but where?

Remember, you're not trying to do comprehensive tests to verify things are "correct". Just that they do what you want. I only write tests that force me to write new lines of code. I actually don't spend too much time worrying about boundary conditions, only the obvious stuff (a player's life shouldn't go below zero).

Have fun and give us another update in a few weeks to see how things are going.

--Noel