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.
Recent Comments