@nomadic_leader: (... never mind, ninja'ed by Gothars. Pretty much everything I was going to say.)
@Alex - Speaking of testing, I was wondering how you go about doing the testing on your end. I've been doing a bunch of work on an Android game lately, and it never seems very clear on where/when/if to start using unit tests and whatnot. Admittedly, I'm still building the core bits of the game engine, but I'm having trouble finding any clear places to insert tests and QC stuff (especially for classes that handle user input and whatnot). What have you been doing in that regards? Figured I'd ask since your stuff has generally been pretty bug-free in my experience.
Well... in my experience, unit tests haven't been useful for much of anything. If you're working on a math or string library, especially with multiple committers? Sure, unit tests would be *great*. Something more real-world, though? It just gets a lot less practical. Also, as you point out, there are issues when you start dealing with user input. Still could be worked with using mock objects and such, but to me the extra effort, extra complexity, and saddling the code with stuff that makes it harder to change just aren't remotely worth it.
Personally, I just try to minimize the opportunity for bugs to creep in (i.e. don't do anything fancy, put in null checks where you don't think you need them, that sort of thing), and test the code at the time of writing it. And never assume that the simplest change you made is just going to work. The number of times I thought it would, tested anyway, and then found a bug are too many to count. I think it's more of a mindset thing than anything.
Of course, bugs still do creep in. But they do with unit tests, too. In the end, I think it's finding something that works for you. Even if it involves unit tests; I won't judge