RBIPhoneTest Oddities?


Of course I don’t expect things to work 100% so it’s no surprise that I found an oddity in the RBIPhoneTest project (brought to you by Dr. Nic). No discredit at all toward Dr. Nic, as he did a fantastic job with what little Apple gives you. Maybe it’s my misunderstanding of Ruby testing and the ZenTest autotest thing but I got autotest running since finishing that screencast last night and I noticed that inserting a simple “assert_respond_to” call started showing a test failure when I thought it should pass. I then found something even funnier. After commenting the failing “assert_respond_to” call the test passed! Yes, that’s not really funny but get this. I uncommented the very same line that was failing and got the test to pass!! Now that’s funny! not in the “haha” sense of funny but more in the “things that make you go hmm…” Arseniol Hall kinda funny. It’s repeatable as well. I change the message name in the responds to assertion to make it fail, change it back to make it right but it still fails, comment the line to make it pass, uncomment and it still passes! More on this later…

iPhone Unit? TDD?


Thank God for people like Dr Nic. I managed to test drive a simple calculator project on the iPhone using his screencast. Just a quick note if you don’t come from the Ruby camp, (you know, like you spend most of your time obsessing over the JVM and toy with Groovy on the weekends):

You’ll want to install rubigen to get his example to work.

sudo gem install rubigen

You’ll also find that since the project renaming iphoneruby doesn’t work. Instead “gem install rbiphonetest”. My only question is why doesn’t my calculator respond to the reset method after I completed the screencast walk through and added the reset method to the object?

assert_respond_to calc, :reset

fails for me! Must be another one of those iPhone/ObjC inconsistencies that I’ll learn along the way.

If you try to fail, and succeed, which have you done?


From T.D.D. training two weeks ago I learned that failing is just as important as passing. More specifically certain tests are expected to fail and you need to verify that they do. It’s a little counter intuitive but think about it. The first kind of failing test that deserves our attention is the initial test. The first time you write a test it should fail and you should verify that it does. That ensures that you are actually adding the intended behavior when you finally do get a green bar.

Another type of important failure is the resilience test. These are test that check your code’s resilience to bad input. Lets just pretend that you have this:

class TeleporterTest extends TestCase {
   public void testTeleport() throws Exception {
      Teleporter hiro = createTeleporter();
      hiro.telelportTo(new Planet(Planet.MARS));
   }
}

Here we are exercising Hiro’s ability to teleport to other planets which we would expect to fail. (It should fail because there’s no oxygen on Mars which would in effect kill our Hiro or Hero, if you will.) We want our Hiro to throw an Exception on inter-planetary travel… something like InterplanetaryException. This is a situation where we try to fail. If you run the test as is and it green-bars what have we done? Have we succeeded or have we failed? It’s a really mind-twisting bit of code the first time you write such a test because you have to think opposite then opposite of that opposite then rationalize the intent of double negatives and all.

So how do we assert an Exception in JUnit? (It turns out that the folks at CxxUnit have done a much better job at the task.) First you have to execute the code that you’d expect to throw the Exception as above then you have check that the exception is thrown. The easy way to do that is to put another line of code after the line you’re testing, an “if-we-get-here” line. Because if we get that far then the Exception hasn’t happened which means we’ve failed.

class TeleporterTest extends TestCase {
   public void testTeleport() throws Exception {
      Teleporter hiro = createTeleporter();
      hiro.telelportTo(new Planet(Planet.MARS));
      fail("Hiro shouldn't teleport across planets!");
   }
}

We run the above and get our red bar which tells us to change/add the logic necessary to trap for bad input. Assuming the createTeleporter() method just returns “new HiroNakamura()” we’d do something like this.

class HiroNakamura {
   public void teleportTo(Object location) {
      if(location instanceOf Planet) 
      { throw new InterplanetaryException(); //extends RuntimeException }
      //...
   }
}

But wait! That causes our test to error because an exception is thrown. You have to catch the exception in your test so that the test framework doesn’t catch it and abend. We do something like this:

class TeleporterTest extends TestCase {
   public void testTeleport() throws Exception {
      Teleporter hiro = createTeleporter();
      try {
         hiro.telelportTo(new Planet(Planet.MARS));
         fail("Hiro shouldn't teleport across planets!");
      } catch(Exception e) {
         //we expect an exception which means we're good
      }
   }
}

Now we’re in big trouble. It is so typical to make the above mistake then live with the consequences days or months later. (If you know where the problem is keep quiet so the people in the back can concentrate.) What happens if later on somebody removes the guard clause in HiroNakamura? Or what happens when we create a new Teleporter implementation (PeterPatrelli) and attempt to reuse the above test logic? Let’s consider the first case where somebody thinks that the Planet object would be necessary for qualifying a location. In other words we want to be able to teleport to “Planet earth = new Planet(Planet.EARTH)” after we’ve set a country on it like, “earth.setCountry(“Japan”);”. So we remove the check at the beginning of Hiro’s teleportTo method and the test passes! That’s no good because now we can also send Hiro to Pluto and freeze him to death. The problem comes from the fact that we set out to fail and succeeded in failing which gave us a false sense of success. (That makes sense, right?) Instead should we have set out to succeed in failing and properly asserted our failure for success? Let’s look at our test.

class TeleporterTest extends TestCase {
   public void testTeleport() throws Exception {
      Teleporter hiro = createTeleporter();
      try {
         hiro.telelportTo(new Planet(Planet.MARS));
         fail("Hiro shouldn't teleport across planets!");
      } catch(Exception e) {
         //we expect an exception which means we're good
      }
   }
}

Why is it no longer failing when the Exception doesn’t happen? What’s really going on? Well we teleport and then we run the “we-shouldn’t-get-this-far” line and that should fail the test right? Well it would fail the test because it throws an AssertionFailedError which we blindly catch as Exception and silence with our naive comment that states stoopidly that we expect an Exception. (Never ever EVER catch or expect Exception!) Instead we should have caught the right type of exception which would not only self document the intent of the desired behavior but would have kept us safe from future modifications.

class TeleporterTest extends TestCase {
   public void testTeleport() throws Exception {
      Teleporter hiro = createTeleporter();
      try {
         hiro.telelportTo(new Planet(Planet.MARS));
         fail("Hiro shouldn't teleport across planets!");
      } catch(InterplanetaryException e) {
         //we expect an InterplanetaryException which means we're good
      }
   }
}

So now I ask the above question. If you try to fail, and succeed, which have you done?

Ten T.D.D. Commandments


Update* A while ago I thought it was cool to use the file system during a test but a little bunny taught me otherwise. I’ve removed a redundant commandment as well.

Inspired by Ashcroft… not that Ashcroft but this one.

Ten Commandments of Unit Tests

1. I am the class being tested. Thou shalt not test any other class but me.
2. Thou shalt NOT write implementation without a unit test.
3. Thou shalt ensure the bar is red before any code is written.
4. Thou shall NOT write two tests which depend upon each other
5. Thou shall NOT test private methods.
6. Thou shall NOT access files during unit tests.
7. Thou shalt always refactor both test and implementation code after every green bar.
8. Thou shall NOT worship (or test) any false classes (mocks).
9. Thou shall NOT define more than one behavior in a unit test.
10. Thou shall NOT commit code without green bars on all tests.

I don’t care about test coverage


If you’ve been here a few times you might get the impression that I’m a fan of T.D.D. Certain things like the fact that I’ve created a project devoted to Test Driven Design, or the fact that I go as far as foregoing the T.D.D. maiden name in favor of its newer alias B.D.D., or even the fact that all I can talk about when I’m drunk is using interfaces and abstract classes with JUnit may give you the idea that I think of the practice as more than just a practice. Yes, lady and gentlemen… I believe in Test Driven Design. I believe in it so much that I’ve substituted it for one of my three daily square meals. I sleep under JUnit bedsheets with little green frogs colored on them. I even used T.D.D. brand peanut butter on my sandwiches. But… BUT!!! I don’t care about test coverage. That’s right. I don’t care if 30, 60, or 90 percent of my code is covered with unit tests. I’ve run the clover plug in for Maven in the past and while the generated report looks cool I could care less for what’s tested and what’s not.

I’m not hypocritical at all. I don’t write tests for the coverage. I don’t write tests to prevent bugs. I don’t write tests because my leadership wants me to. None of that means anything to me. Many people use one or more of these reasons for pursuing unit test development but I’m here to tell you these are all the wrong reasons. If you find yourself obsessing over test coverage then your doing yourself and your project a dis-service. If you primarily want to find and trap with your test suite then your suite is garbage. There is only one reason to write unit tests, my friend (We are still friends, aren’t we?) And that reason is for the interfaces. Don’t get me wrong, those other reasons are good things to have on a project but none of them is nearly as important as usable interfaces.

I’m writing tonight because those former reasons listed above are actually becoming my pet-peeves. People using them for writing tests completely miss the point. There are two types of unit testing. There’s Test Driven Design and then there’s Testing While Designing (TWD). TWD is probably the more popular approach and has tons of developers confused and fighting with the technologies. When you do TWD you end up with the very crippled and highly coupled design the TDD is supposed to alleviate. You also end up with very brittle tests that fast fall out of date with the corresponding source. When you practice T.D.D. your tests are never out of date because they precede or drive every bit of code you write. So as I already said, test coverage becomes irrelevant. It’s a given. A bonus. A perk. A consolation prize. It’s the toy wrapped in the plastic baggy sitting in the bottom of your Cheerios. The spare tire in your trunk. You know you need it but you don’t go all, “you gotta see my new Car! Mileage per gallon? I dunno, but check it out. It has a fifth tire tucked in my trunk” You… just… don’t… think… about… it. Who cares?

You don’t go looking to maximize test coverage when you do T.D.D. any more than you go looking to put a white wall or a mag rim on that fifth tire. I’m just a little worked up tonight because that’s the attitude I’ve seen in some people lately. I won’t name any names but I’ve heard some podcasts trying to explain the benefits of T.D.D. and I’ve seen other developers make speeches about recent projects with test coverage being one of the highlights. It’s starting to really get my goat. I don’t like when things get my goat… because it’s MY GOAT. Go get your own goat. Why you gotta be all on my mountain, jacking my four legged pet???!! If you can’t get a goat go sheep herding. I don’t care whatever! Just leave my goat where it is. I don’t come in your neck of the woods messing with your livestock do I? What was I talking about anyway? Oh yeah! Goats! I gotta get some shut eye… Holla if ya’ feelin’ me…

FallFramework For Mobile


Not too shabby… I think I can say it’ll probably do something close to what I think we might possibly need… almost…

What am I talking about? Hi, I’m Cliff and you’re here because you’d rather writing a turing machine in Scheme rather than figure out if the 49’ers trumped Ravens in the 4th quarter. (By the way, they didn’t.. doggonit!) Recently I switched from being Joe Cool Java/Linux dude to Radical JavaME/OSX guy and it’s been an adventure. Coming from a mostly mainframe server-side programming career I take certain things for granite. (I sometimes take granite for sulfur and later take sulfur smelling brown chunks to the toilet but that’s another topic entirely.) Normally, with like JavaSE, you can like, do really cool agile things. Y’know like program to interfaces and do setter based injection with reflection, late binding, and dynamic class loading. But with JavaME you gotta be reeeaaally really clever and do egg-headed stuff like making sure you have more fingers than occupied bytes in memory, hard binding to concrete objects… cuz like you can’t use Class.forName or a classloader, and worry about tail recursion and loop unwinding. Well old habits die hard like Bruce Willis (yeah, that was a really dumb analogy). So I decided to do something about the short-comings. That makes me feel smarter than you because I did something about it and you didn’t. If you were smarter you would have beaten me to the punch and come up with an even better idea. Alas my intelligence and attention to detail overpowers your meager “it has to be this way” attitude, so neh!

Insults and arrogance aside lemme tell you… I think I might have something. What I have so far is the buddings of what I’d like to label the Fallframework. It’s nothing to brag about (which is why I brag on) as it does yucky code generation. Before you start with the “How dare you code generate in this day in age!” I wanna ask how would you handle the problem? You need to decouple you object model. You have a bunch of objects that depend on interfaces. You can’t use reflection, you can’t use class loaders, you can’t call your mother (cuz she doesn’t know Java), and you can’t poll the audience for help. Well I lean on XSLT (because I like it, and because it’s a really cool language, and because it’s perfect for transforming XML, and because it gives me more to brag about) to process a Spring Beans descriptor and generate a BeanFactory that can return any object declared in the descriptor. It’s still basic right now in that it requires you declare types for dependencies but I plan on adding a little compile time classpath navigation for class introspecting which should allow for the same kind of type coercion/conversion found in the Springframework. Here’s a sample of what it does so far:

I can take this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="myBean" class="com.mapquest.javame.MyBeanImpl">
        <property name="someValue">
            <value type="java.lang.String">Run D.M.C.</value>
        </property>
        <property name="someOtherValue">
            <value type="java.lang.String">27</value>
        </property>
        <property name="someNumber">
            <value>11</value>
        </property>
        <property name="someArray">
            <value type="int[]">1,2,3</value>
        </property>
    </bean>
</beans>

Into this:

package com.mapquest.javame;

        class FallBeanFactory {

      public com.mapquest.javame.MyBeanImpl getMyBean() {
          com.mapquest.javame.MyBeanImpl bean = new com.mapquest.javame.MyBeanImpl();
              bean.setSomeValue("Run D.M.C.");
              bean.setSomeOtherValue("27");
              bean.setSomeNumber(11);
              bean.setSomeArray(new int[]{1,2,3});

              return bean;
            }

        }

So now you can practice T.D.D. with mobile
JavaME has to be one of the more challenging frameworks in which to practice proper T.D.D. Not only because of the difficulties with supporting a decoupled design but also because the industry, runtime, and your co-workers, practically tattoo early optimization on the insides of your eyelids. However I still feel it is best to stay true to T.D.D. (or B.D.D.) and optimize where/when necessary. I’m still new to embedded stuff and I’m waiting for my team or my Blackberry 8830 to prove me wrong (my last sprint demo did show incredibly slow processing) but I maintain the faith. It’s getting late so I’ll leave you with those thoughts. (If you really wanna argue with me… put technical details where my eyes can see…)

FallFramework


I threw something together that does dependency injection for this mobile project I’m working on. You see with mobile, you’re kinda limited with what you can do. There’s no reflection, no runtime dynamic class loading, not even a Url object. So this seemed like something of a challenge. But I got something… something that does dependency injection… something that wires the app together. It’s really crude right now using a properties file, but I’m looking to support a subset of the Springframework XML schema. I think I can have this working if I give a solid eight hours on it.What I’m dreaming up is the FallFramework. And how appropriate. It started in the fall and it’s similar to the Springframework.

How did I do it?
I did what any developer would do with no classloader, no reflection and one hand tied behind my back. I code generated. Why code generation? It stinks right? Code generation is soo last 2003 with the smell of anti-pattern engulfing it’s very name. Why would I go to such extremes, especially for a mobile app? I’ll tell you in one word, Test Driven Design. (Yeah that’s three words but I spell it as T.D.D. which makes me right and you dumb yet you continue to read after being intentionally insulted which makes you unbelievably stoopid while you still read past a second disrespectful and intentional remark which makes me unbelievably arrogant knowing I have your undivided attention this far leading to yet more clever ways to sneak derogatory insinuations across your faithfully reading pupils.) That’s right, Test Driven Design calls for some means of assmbling or putting togther the app which calls (collect) for dependency injection. Since I’ve sworn off writing even one package statement without a preceding test case of some sort I need a D/I solution so that I can be productive. With one no code would be written because I can’t write a test for a class that’s hardbound to another class. So now I have a temporary solution involving code generation.

So whatd’ya think? Is there something out there already that can wire a J2ME app together? Please tell me b/c I’d love to just drop it into my project and run with it. Does it sound feasible, what I’m attempting, I mean. Has anyone else tackled this problem? If so, what did you do? Spil your grey matter in the square below while I interrogate for any useful ideas. I may need you to sign a waiver indicating that any think meat, ideas, brainstorming sessions left on this site becomes property of yours truly. Drop the science on me…

(Dropping science is a term I first encountered in the early nineties among some of my hip-hop speaking bretheren. It refers to the processes of divulging knowledge which is considered “heavy”, revealing, or insightful in some way, knowledge which commands the respect of those who receive it.)

SpringframeworkME


Eye catcher? Original idea? I’m surprised it’s not done already or if it is it’s soo difficult to find. Why would anyone deploy something as heavyweight as the Springframework on a mobile device? Wait a minute? Spring is a lightweight container right? Well not exactly. When you consider mobile devices there’s light weight, then there’s low cal, then there’s skim. A 1+ megabyte jar can’t be deployed on a mobile device, for startes. Then Spring requires class-loaders and reflection. So where does that leave us? I’ll tell you where. It leaves us with the idea swimming around my skull. The idea is bright orange with white stripes, swimming in circles due to it’s right side baby fin.

Here’s the deal. The idea behind Springframework can work in JavaME barring we take a different approach. Remember, no reflection, no classloading. That leaves us with compile time assembly which is all you can hope for with JavaME anyhow. So why would we need Springframework in JavaME? Maybe I’m far off but I think you’d have to do something similar when practicing T.D.D. Interfaces need to be pluggedand collaborators shouldn’t know one another. If you have a better idea than what I’m thinking about, drop some knowledge in the comment cage down low.

Sensible Early Optimizations


The bulk of my frustration lately is dealing with the concept of early optimizations that make sense. The idea came up in a recent discussion and I feel I should have challenged it. Once again, I’m developing for a very unique type of hardware that does require tight code, so there’s some unfamiliarity and apprehension involved. Still I wrestle internally with what seems to me like the wrong approach. In practice, any practice, are there any optimizations that make sense early on and don’t bite you after an iteration or two? I’ve run across a couple so far and I’m trying hard to bite my tongue. I guess what I really struggle with is the unfamiliarity I have with the platform as well as the unfamiliarity others have with the agile approach. It’s supposed to be about incremental improvement. That is you lay out the req’s in test form (or as a GSpec, wink, wink) spill out the first ugly solution (which in my case happens to be a shameless copy of existing code), and iteratively improve the implementation as well as the test. There is no getting it right the first time, or big round of cleanup and optimization at a later date. It’s all done at once, the interfaces being key.

I just got a green bar on a very tough piece of logic and I’m not satisfied with the implementation. I was driven down certain paths because of sensible optimizations. I now have the unfortunate task of undoing at least one of these sensible optimizations and explaining my changes. The project is very young so it’s not too big of a pain. The technology is new so I still stand the chance of being horribly wrong. However, my practice and my experience is yelling quite the contrary. That’s enough yapping from me. Time to refactor.

The optimal approach


So I’m doing this embedded development right? And now I work with a bunch of guys that don’t obsess over pretty code, organized packages and outside in development, and easy build systems like I do. Things like public access members (and public access television) are considered the norm while method body size takes a back seat. I’m ok with some of the concerns: smaller memory means don’t spin up a bunch of object, use arrays over collections, change your underwear before going to bed, all seem like good ideas. What I struggle with (and will probably fight to the death over) is early optimization. I don’t care what device or platform you deploy to, optimizing before green barring is bad. You think you’ll save bits here and bytes there and you might be right. Maybe there’s redundancy between two method signatures and it’s highly likely. However, until you get that green bar you should leave all of the seemingly bloated and unnecessary scaffolding in place. Let your tests do the refactoring. Let your iterative design process shake out the redundancies. Small rant for now. Much more to come. If you’ve ever been in a situation where optimizing before getting a green bar saved your job (or rescued your cat) I’d love to hear from you. Include your life altering story in the square below, inquiring minds wanna know…