In my case it's simply because I'm writing this entirely by my self, and I'm trying to get as much stuff in/fix things as quickly as possible which inevitably leads to errors. In addition, in my many years as a professional dev, I've never seen anyone work to a TDD - they were all the rage in 1998, and swiftly abandoned by EA and Microsoft thereafter. This is partially because - unlike most other software - the actual design of game systems changes rapidly. This is exacerbated as teams get smaller, resulting in a large line-of-code-per-coder ratio; basically, the fewer people you have, the more impact any one person tends to have (by necessity). Since there's less need for communication between a team of, say, 'one' many things are simply held in the mind of the coder, and you'd easily double the length of development writing and re-writing TDDs, and the 'try it and see' prototyping methodology would fail as speed gave way to doubt.
Large projects with very few inputs and outputs in a non-realtime system (say payroll, where I worked as a coder, briefly, at IBM) the expected outputs on any inputs are 100% known. Writing software to spot deltas between expectation and actual results is relatively trivial. Games are a lot more complex, with a lot of chaotic interaction, and it would often take longer to write test cases than it would to 'try the feature out' and get errors.
In the particular case you mention, I *could* have isolated inputs and outputs, and written a test script to ensure this was occurring. But that only makes sense after the fact, once the problem is perceived. For this to be effective as a general strategy, I'd have to write code covering every input and output in the game, under every random level generation, with every variation of key-press pattern. This is simply not tenable, and almost certainly the reason most AAA teams do nothing of the kind outside of a couple of locked down, easy to test areas. At most, they'll write a 'bot' to complete the game and ensure they've not completely ruined it with the latest fix.
This is the case for most AAA games, and why test-teams are the usual method of weeding out this kind of thing. Since Spellrazor is a free game, creating additional costs for testing would be inadvisable at this stage. As a result, I'm using you kind folks as guinea pigs.
I hope you don't mind too much. :-)