Programming while stupid

A significant benefit of test-driven development (TDD) is that you don't need to work very hard. Now turn that idea around: when you cannot work at your full capacity, you can still be productive and produce well designed, working code.

TDD reduces cognitive load by encouraging small steps and by capturing the precise requirements for a piece of code in the test's assertions. Typically, that allows us to devote more of our energy to other important matters like clear design, intention-revealing code and delivering value to the customer.

But what if you're tired? What if you're just not at your best? It happens; we're human! Sleep deprivation makes us stupid. So does stress.

How are we supposed to program while stupid?

Maybe you have a teething baby. Maybe you got into an accident on the way to work. Maybe the office is absolute Bedlam today. Maybe you're hung over. (Note: I have never experienced this latter phenomenon, though I believe I may have read about it in books.)

The rhythm and structure of TDD provide enough support that you can still be productive. Granted, those "extra cycles" will not be available to perform the higher level functions we mentioned, such as keeping an eye on the broader design of the code. But at least you'll be able to function. You will be able to program - without embarrassing yourself.

Contrast this with situations in which intense focus and concentration are an absolute requirement for producing any code at all.

Before I learned to TDD, I would keep large chunks of infrastructure in my head. Needless to say, such a volatile storage mechanism had to be treated with great care. An overheard conversation or a phone call could cause enough of a distraction that I would lose track of what I was trying so desperately to keep aloft. I'd get frustrated and angry. Back in my wilder youth, I'd often call out loudly for peace and QUIET!!

And what about the morning after a colicky baby all-nighter? You've made it in to work. You want to sling some code. You have a moral and ethical obligation to do something useful to earn your pay. But keep a complex design, a lofty edifice, a convoluted algorithm in what remains of your battered brain? Not gonna happen.

So don't even try. Take baby steps, write the asserts first, be modest and methodical and your work-ethic conscience is assuaged.

I still don't enjoy distractions, and having learned a lot more about neuropsychology over the decades, I decry the misplaced affinity for multitasking that some people seem to think is a necessary part of modern life. But I can happily walk away from a red test, knowing that I can pick up at any time and, by continuing to take baby steps, finish what I was doing.

Interruptions are more tolerable with TDD. A trance-like focus is no longer a basic prerequisite for programming.

And TDD cures hangovers.

Class: Robot Programming with leJOS

I am teaching a class on robot programming with leJOS as a follow-up to my "Programming with Scratch" class. LeJOS is an embedded JVM for LEGO Mindstorms. I started with a 30 minute tutorial on Object Oriented programming (what's a class? what are instances, methods, inheritance and polymorphism?) Yes, 30 minutes.

Then we jumped straight into test-driven development with JUnit and my own library that sits on top of the leJOS API. (I had to make this layer because leJOS objects are untestable.) Predictably, this was challenging, but not impossible! However, since we're dealing with fake (testable) motors and light sensors and so on, the production code we write doesn't cause physical wheels to turn and so on. That makes this all very abstract. It's a healthy stretch for a 12 year old, but they're doing it.

We took 15 minutes out to begin assembling the robot, and wrapped up the session with a brief retrospective.

Next week we'll download some of our code and watch the robot move (assuming we can build the damned thing!) Then we'll continue test-driving more behavior.

This is cool!

Test-driven development with leJOS in Eclipse

I have a working setup and have been happily test-driving development of an embedded leJOS app all day!

I created one project for the app itself (CUT - code under test). It has only the leJOS classes.jar (and no JDK/JRE classes) and uses the Eclipse Java Builder as would a standard Java app.

I created a second project for the tests. It's a plain Java project. It has the CUT as a project dependency.

Now for the code that made this possible: For several of the classes (Motor, LightSensor, etc) I had to make special decorators so that I could mock them.

For example, I have an Eye class that has-a LightSensor and which implements setLightValue() in addition to the pass-through getLightValue(). In my tests, I have a TestableEye subclass of Eye that simply remembers the value passed in to setLightValue() but does not call the underlying LightSensor at all.

I did the same thing with Motor. There's a decorator with a "Testable" subclass.

Now my unit tests (when we teach this stuff, we use the term "microtest" because it's less confusing to the QA folks) I simply instantiate a robot with a bunch of TestableMotors and TestableEyes. The microtest then exercises all the hairy logic required to get data from the eyes and drive the motors.

This is a pretty strong proof of concept. I expect to build up a few of these decorators to work around the issues with the leJOS design philosophy, specifically that work is often done in the no-args contructor. That makes them extremely difficult to subclass for testing purposes (that is, to mock.)

Epilogue
I was told this in the leJOS forums:

Note, that on the NXT, only the classes in the file classes.jar are available, and that this contains only a limited subset of the JDK APIs. For example, reflection is not available. Ergo, JUnit will not work.

There's something about proving people wrong when they say "it cannot be done."

TDD with LeJOS

My "Programming with Scratch" class has come to an end. The 5 girls had fun with it, and voted to move on to Java programming rather than continue in the world of Scratch. Specifically, I promised them LEGO Mindstorms with Java, or to be precise, LeJOS.

I am a diehard TDDer, so of course I shall be teaching Java programming test-driven. But test-driving with LeJOS is challenging. Because LeJOS is an embedded system, it uses a pared-down version of the Java class libraries and a custom JVM. The LeJOS system does not support reflection, which is required by straightforward JUnit. So how will we approach TDD with LeJOS?

One option is to build our LeJOS apps using the normal JDK – after all it's all syntactically correct Java. We can then test-drive all aspects of our logic while mocking things like motors and sensors. Of course, this only gets us so far. The real snag is that we will be test-driving in one environment and running in another. Any time you have a mismatch between dev and production environments, you end up with a problem, and in this case, the difference is quite significant: Not only are the JVMs quite different, but the languages themselves (in the broader definition) are dissimilar.

I'll be looking into this issue and posting more as I learn more.

Test harness for Roku's BrightScript

Roku has finally released their SDK for making "channels". Unfortunately, the Roku box runs a proprietary, BASIC-like, non-OO language called BrightScript. Happily, Mark Roddy has written a test harness so you can TDD in BrightScript.