I’ve always admired Test Driven Development and longed for it from afar, but never had a chance to use it until I was on my own project. Most times when you crave something this intently it’s a let down, but no, this is every bit as fun as I thought it would be and more. It’s so relaxing, and it takes so much less mental RAM. I won’t go back to any other way.
I keep trying to explain why it is better and exactly how it made it obvious what I needed to do, but everything I write comes out boring and I don’t think it explained it anyway. Let’s try an analogy. You know how when you attempt a big cleaning project the middle looks worse than if you’d never started? And if you misjudge your energy level it stays that way, and then gets worse because you’re still living your life? Or maybe you misjudged the amount of space something required and your plan becomes unworkable, at which point you can improvise or revert? That’s what regular coding feels like to me. You don’t know if something’s working until it’s all working.
I’ve been cleaning up my apartment lately, including getting rid of things I don’t want and rearranging things I have so they are more accessible/easier to find/take less space. And I am being very careful not to do that. I pick tasks that can be done incrementally. If I want to move things from cabinet A to cabinet B, things in cabinet B get moved to cabinet C first. But cabinet C doesn’t have to be their permanent home, just a pareto improvement over the old one. I have consolidated three dressers into 1 + some other storage bins. I will probably rearrange those storage bins and the remaining dresser as I learn more about how the current arrangement works, but I was never going to be able to plan that out ahead of time anyway. This way I never get stuck halfway through, out of energy or realizing my plan is unworkable.
That is what TDD feels like to me. You might technically be writing and erasing a lot more code, but the mental effort is so much less. Every step leaves you a little bit better off, and you can concentrate your efforts on one problem at a time.
I was really unimpressed with the android tutorials I saw. I did Udacity’s, which is officially recommended by Google, but didn’t provide reference code or a way to check your project, so if something didn’t work you didn’t know where the error was. That’s bad enough when it’s a technology you’re well versed in, but with a new tech you don’t have any debugging tools. It’s like trying to learn a foreign grammar by having it explained to you in its own language, when you don’t even have any vocabulary yet, except your brain hasn’t been crafted by millions of years of evolution to do it. There are other tutorials, but most of them were written for the now-deprecated Eclipse IDE. Translating from one IDE or build system is not a big deal when you’re familiar with at least one of them, but at the beginning you don’t even know what to Google. That’s why you’re doing a tutorial. It’s even more fun with Android because it uses a bunch of very common Java tools but requires slightly different usage than everything else.
So what I actually did was do Udacity long enough to know how to make baby’s first project, come up with a concept that I was pretty sure I could subdivide into google-able problems, and then did so, one at a time. I learned testing basically from scratch, because the two tutorials that covered it required me to know a ton of abstract android architecture, and none of it was explained well enough to mean anything unless you had already coded. “Make minor changes until you understand the permutations” is how every programmer I know learns, and yet no class teaches this way.
All of which leads me to believe a test-driven tutorial could be really useful. I’m picturing a project with a few very simple UI elements, and a series of commented out tests. Users would uncomment the tests one at a time, in order. The test would fail. The error message would be informative, maybe there would be a few suggestions for how to solve it. Then they would research on their own until they found a solution. They would know they had done it right because the test would be passing. Plus they’d learn testing tools at the same time, and those are extremely useful. This may be my next project.
TDD got me all of the features I wanted in HungerTracker 0.2 except notifications. I’m still poking at it, but notifications require a deep understanding of several concepts I’ve entirely ignored until now, and need several moving parts to work together to verify any of them. So here’s version 0.2, which has a greatly improved button layout and a scrollable list that shows as many or as few entries as actually exist.
Aceso Under Glass 