Learn 2 Code TDD Style


So it’s a Wednesday night & I won’t be able to sleep unless I get this post out. Overtime I get to talking about Agile and TDD I go overboard. Hi, I’m Cliff. You’re here because you wanna know what this TDD style learning thing is all about. I’m here because I shot off my mouth over Twitter ’bout some stuff I had no business talking about. Now I gotta make something out of my tall order claims. Here I will attempt to stretch the limits of a simple programming construct as well as the limits of your imagination in my explanation.

The approach I’m going to explain is something I learned from Dierk König in the Groovy In Action book, I take no credit for the awesome technique and I’m not sure of its origins. The technique is language agnostic, will out live your written wiki documentation and stays up to date as the code evolves. So now that I got your attention, let’s get started. (Disclaimer, though it is language agnostic I will be explaining using Java syntax. Different languages/platforms may behave differently.)

What’s an assert?

This question came up in the Twitter chat so we’ll start here. (BTW, I’m really starting to dig the #CodeNewbie chat because they ask the cutest questions like, “what’s an assert?”) The basic function of an “assert” is to check a value or an expression and its form (again in Java) is:

assert (expression) : "error message when false";

The expression can be any boolean expression and the message is whatever you want to see when the expression fails. You can have something like

assert 2+3 == 1024 : "I'm not good math";

Then when you run this code it would explode your computer sending shards of silicon in random directions. Actually it would merely fail the process and dump the error message and expression to the console:

java.lang.AssertionError: I'm not good math. Expression: ((2 + 3) == 1024)

Next you could try something like

x = 3;
assert 2+3 == 1024 : "I'm not good math";

which would dump the following error to the console:

java.lang.AssertionError: I'm not good math. Expression: ((2 + x) == 1024). Values: x = 3

The interesting thing here is the way the values are dumped to the console. I’ll explain why this is so significant in a moment but for now let’s move on. You could have something more involved like this (assuming you have a guessMyAge method that lives somewhere):

result = guessMyAge();
assert result == 39 : "I think I'm 39 years old last I checked."

If the guessMyAge function can work magic then the code would run without failing. However, if magic really doesn’t exist in my Macbook pro and it really couldn’t guessMyAge then I might see something such as:

java.lang.AssertionError: I think I'm 39 years old last I checked.. Expression: (result == 39). Values: result = 109

I would then say, “Nice try Macbook. I get to pick a prize now, right?” All dry jokes aside, you might notice a pattern here. To make it clear I’ll give another example. Pay close attention because I’m going to try to confuse you.

Let’s say you had a method named “fib” defined somewhere and I gave you the task of designing an app with this function. You might panic and be all, WTH??? What is “fib”??? Or you might try something like:

assert fib("I have bad breath") == true : "I really should not have bad breath";

You would do this because you would be asserting the sentence string you give to the fib method is a “fib” or a false statement. Furthermore you might be guessing that the fib method does some sort of lie detection so you would assume passing a fib to a fib detector would return true indicating that you do NOT actually have bad breath. Again, unless your computer has magic inside you would probably get a compile error saying that the fib method takes an int parameter and returns an int value. (This is the confusing part where my example an my dry humor jump the shark.)

Sloppy humor aside. Let’s take the fib example again. This time we know that it takes an int parameter and returns an int value. We could do something like so:

int x = fib(1);
assert x == 0 : "I really don't know what this does";

Here we are setting the value of x to the return of the “fib” method without really knowing what “fib” is or what it does. We use the value in an assert and when we run it we get:

java.lang.AssertionError: I really don't know what this does. Expression: (x == 0). Values: x = 1

If you look carefully you have a valuable piece of information, “Values: x = 1”. You Didn’t know this before. We can copy and paste the value back into the assert and change the error message:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

That’s not so interesting. but watch what happens when repeat the code with a few different parameters.

x = fib(2);
assert x == 1 : "fib(2) should be 1";

x = fib(3);
assert x == 1 : "fib(3) should be 1";

x = fib(4);
assert x == 1 : "fib(4) should be 1";

We are changing the passed parameter in each case but keeping the assertion the same. After a little experience coding you might notice that usually when a different parameter is passed to a method you get a different value returned, so what gives? Think a moment. If you run this code and repeatedly copy the errors from the console back into the assert you would end up with this:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

x = fib(2);
assert x == 2 : "fib(2) should be 2";

x = fib(3);
assert x == 3 : "fib(3) should be 3";

x = fib(4);
assert x == 5 : "fib(4) should be 5";

Everything looks sort of predictable until the last line where the number jumps to 5. A few more iterations give you:

int x = fib(1);
assert x == 1 : "fib(1) should be 1";

x = fib(2);
assert x == 2 : "fib(2) should be 2";

x = fib(3);
assert x == 3 : "fib(3) should be 3";

x = fib(4);
assert x == 5 : "fib(4) should be 5";

x = fib(5);
assert x == 8 : "fib(4) should be 8";

x = fib(6);
assert x == 13 : "fib(4) should be 13";

x = fib(7);
assert x == 21 : "fib(4) should be 21";

If you have a background in computer science or have spent a lot of time programming in your career you might recognize the series of numbers emerging as the fibonacci sequence. What you have done is explore a method without knowing if was a lie-detector or a numeric series generator and through a process of iterating with different parameters and asserts you discovered its behavior. Furthermore you have documentation in the form of sentences describing the method. You could come back weeks or months later and see what the method does without looking at any of the code inside the method.

This approach works particularly well with methods in Java but how does that help you learn anything? Well, because the assert is so incredibly simple you can use it anywhere and with any programming construct. For example what does the following left shift operation do?

int x = 32 << 3;
assert x==0 : "What does this do?";

java.lang.AssertionError: What does this do?. Expression: (x == 0). Values: x = 256

Becomes:

int x = 32 << 3;
assert x==256 : "Left shift 32 by 3 should result in 256";

But what does that that actually do? A Java programming manual would say something like binary bit shifting. You can lookup the Javadoc for the Integer class to see how numbers print in binary form. Then you can use an assert to make the entire picture clear:

assert "100000".equals(Integer.toBinaryString(32)) : "32 in binary form " + Integer.toBinaryString(32)
assert "100000000".equals(Integer.toBinaryString(32 << 3)) : "32 left shifted by 3 in binary form " + Integer.toBinaryString(32 << 3)

Clearly a left shift of 3 shows the “1” bit of the binary number 32 shifted over to the left by three positions. (It would be a little more clear if we added zero-padding but I’m keeping my examples simple.) The best part is that you get documentation as a secondary benefit of using the assert. You can print this next example and post it on your wall as a reference when learning how to bit shift. This is runnable documentation of how bit shift operators work:

assert "100".equals(Integer.toBinaryString(32 >> 3)) : "32 right shifted by 3 in binary form " + Integer.toBinaryString(32 >> 3)
assert "100000".equals(Integer.toBinaryString(32)) : "32 in binary form " + Integer.toBinaryString(32)
assert "100000000".equals(Integer.toBinaryString(32 << 3)) : "32 left shifted by 3 in binary form " + Integer.toBinaryString(32 << 3)

Living documentation
I have another disclaimer. The above examples were all snippets that I actually hacked together using Groovy so they may behave slightly different in an actual Java program but the principle still applies. The idea was to focus on the assert and how it works. I used Groovy to avoid the boiler plate surrounding class definition. Now let’s look at an actual Java program to see how far we can stretch the secondary benefit. Suppose we were given a Java jar file that included the earlier “fib” method and told to use it. We could define a static block in our program and code all of the asserts inside of it as follows:

import static com.company.Funny.fib;

public class MyMain extends Object {

static {
int x = fib(1);
assert x == 1 : "fib(1) should be 1";

x = fib(2);
assert x == 2 : "fib(2) should be 2";

x = fib(3);
assert x == 3 : "fib(3) should be 3";

x = fib(4);
assert x == 5 : "fib(4) should be 5";

x = fib(5);
assert x == 8 : "fib(4) should be 8";

x = fib(6);
assert x == 13 : "fib(4) should be 13";

x = fib(7);
assert x == 21 : "fib(4) should be 21";

}

public static void main(String[] args) {
int num = Integer.parseInt(args[0]);
System.out.println("The fibonacci of " + num + " is " + fib(num));
}
}

The static block documents what we discovered with asserts and runs as soon as the class file loads for the first time. As a result it doubles (triples?) as a sanity check. The assert has performed at least three tasks. We used it to learn the behavior of the method, it now documents what we know, and finally it works as a sanity check as the program runs. What if you get an updated copy of the jar file that contains the “fib” method and the behavior of “fib” changes? The asserts run with your code and dump the current behavior to the console. You merely repeat the process you used initially to discover the behavior and update the asserts accordingly.

How we learn programming languages
When learning a programming language you have two unknowns, syntax and runtime behavior. Learning the syntax is relatively trivial in many cases and usually the smaller part of the learning curve. Syntax is usually validated when you compile your program, and if you iterate adding small additions line by line as we did above then the compiler can almost function the same as the assert.

I find that the runtime behavior is far more tricky to learn and requires the experience of actually running variations of code. The bulk of the runtime behavior involves calling methods/functions in the language. Most languages have a set of functions and classes you must learn to achieve basic functions such as string concatenation, rounding, averaging, manipulating streams, etc. These functions make up the core of the language. In Java you have the Java API. Ruby has the Ruby API, ObjC/iOS uses the CocoaTouch API, and so forth. behave slightly different than what you would expect when you are first learning. Using the assert, you can discover the subtleties of how things behave and the end result is documentation that you can print and hang on your Christmas tree.

This post was intended to explain the power of assert. I actually stretched my examples a bit in a crude attempt to illustrate how assert can be used as a learning tool for beginners. In actually what I was really doing was a light weight no frills form of TDD. While you could start out with assert, In practice you really wouldn’t use a vanilla assert in a program this way. (at least not in Java) There a number of reasons, the first being that assert is disabled in Java and you must enable it by passing a flag on the command line. If you continue with a vanilla assert you will soon see other areas where it breaks down.

My overall intention is to introduce this new way of thinking. I use the assert as a gateway drug to unit test tools with more powerful assert abilities. It is indeed as simple and powerful as I depict in this post and it does have its place, specifically among other languages like Groovy where it is not disabled. (I particularly like the way Dierk used it in his book in lieu of traditional System.out.println statements.) If you find the approach at least somewhat interesting check back later when I attempt to use a more thorough approach to learning with TDD.

Last disclaimer: It is extremely late at night and I made only a feeble attempt at proof-reading/formatting. This is because I get super excited about the topic. There are definitely errors, misspellings/etc. so forgive me.

Robolectric, Ivy, Maven repo drama


For those of you who know me (which would include most people reading this post) you’ll note that I am a huge proponent of TDD and proper project hygiene. I describe project hygiene as the things you do to ensure a successful project with easy maintenance. I have recently been working to prototype such a project in Android but have been hitting several roadblocks along the way. Hi, I’m Cliff. You’re here because you want a nicely structured project. I’m here because I can’t seem to get my project in the right shape, so I’m complaining.

I started a while ago with an example chat app I had written as a guide to using IntelliJ to write Android apps. I even put up a video tutorial on the subject. I recently had been working to reuse my example which had a hard dependency on the Robolectric project. Robolectric is a cool toy that lets you perform REAL unit tests on Android. There are those who may say, I do unit tests all the tim using Robotium, or the Android JUnit packages… but these are not unit tests as they involve either the emulator or a physical device. The tests I have written run successfully on my laptop and take a fraction of the time that typical Android tests take.

I had my environment working about 7-8 months ago but so much has changed since then. Today when I tried to recreate my magic I had trouble trying to “install” Robolectric on my new Mac. (All my work had been setup on my old Mac.) I originally tried running with the older 1.1 Robolectric jar but then had to tweak my IDE envirnment variables to point to ANDROID_HOME which is so much fun on Mountain Lion these days. (It’s practically impossible to get IntelliJ to see custom system environment variables and the launchctl trick doesn’t work for me.) So the nI eventually decided after forcing ANDROID_HOME and getting a path not found on “~/android-sdk-macosx/platforms/android-10” since my new Mac doesn’t have the older SDKs to install a later version of Robolectric. My thinking was, “maybe they’ve ironed out the details and finally fixed it so you don’t need env variable settings and older SDKs…”

If you visit the Robolectric home page you’ll see all the installation instructions point to a Maven POM. that does you no good if you’re starting from an existing Android project because it either
a.) Forces you to refactor your project using Maven standards
b.) Forces you to reverse engineer the pom to find out where the actual Robolectric jar is.
Both of these options are terrible for existing Android work and since many people rarely get to work on green field this presents a tough dilemma.

I eventually found a way to work around the issue by whipping up an equivalent ivy.xml and throwing together a custom_rules.xml to use in my Android project but it still sux on the surface because of the extra overhead involved with declaring a single Maven dependency in an Android project.

Step 1: create a custom_rules.xml.
Step 2: declare an Ant “-pre-build” target that performs the ivy resolve task and writes the dependecy jar files to your project’s “./libs” folder.
Step 3: create a custom ivy.xml that declares your Maven dependencies.
Step 4: Cuss because you realize it’s not trivial to invoke your custom “-pre-build” target in isolation to test your new configuration.
Step 5: Create a custom “ivy-resolve” target which your new “pre-build” target should now depend on.
Step 6: Test your “ivy-resolve” in isolation to ensure it pulls the correct dependencies.
Step 7: Cuss because your IDE’s built-in version of Ant does not include the Ivy jar.
Step 8: Either find the Ivy jar hidden on your hard drive and dump it into your IDE’s antlib or find your custom ant build tools and point your IDE to that.
Step 9: Repeat step 6
step 10: Cuss because your project’s “libs” folder has now exploded with unnecessary transitive dependencies including everything from ant to maven-model.jar to wagon to xerces.jar
step 11: Try to run your tests and realize that the dependencies declared don’t line up with the examples from the web site.
step 12: construct a blog post expressing your frustrations with the current state of Android development.

In the end I’m wondering why, in the year 2013, we can’t do any better out of the box. Why is it still a chore to practice proper TDD on mobile platforms? (I’m glaring at the iOS community as well because I don’t think that camp is any closer to out of the box TDD.) I would love to just open my IDE, click on a unit test, perform some hotkey combo Cmd+shift+F10 or something, and watch either red or green bars stretch across the screen without considering silly stuff like my environment, grabbing older SDKs, researching dependency matrices and the like.

By the way, I found out how to pull external dependencies into an Android project following this blog post. Nice little trick!

How Many Emcees Must Get Dissed…?


So you’re a programmer?
Yes, yes, yes, yes, yes…
I code very deeply…
In about 4 seconds, a teacher will begin to speak
I code very deeply…

Hi, I’m Cliff. You’re here because you wish to know the answer to the age old question, a question that has been asked by many different people over the ages. (Yes some even asked this very question on Yahoo.) This question is generally understood to be it’s own answer. However, in today’s discussion we will revisit the question in code using test driven design as a unique experiment uncover the answer.

Before we begin, some elaboration is in order for those who do not have a background in heavy beats and sentences terminated by rhyming vocabulary. The question we must ask and answer is, “How many emcees must get dissed before somebody says don’t mess with Cliff?” (Astute readers will note that I am paraphrasing slightly from the original.) We ask this question because over the years there have been many emcees who have had their egos reduces to nothing merely because they didn’t understand the exact count or quantitative answer. “Is it 10, or 11? Was my number twelve? Oh, I lost my ticket!”, they would say on their way towards total annihilation. “What is an emcee?”, you ask. It is the phonetic spelling of one MC which (as Queen Latifah explains) is short for “Microphone Commando”. I digress…

So we begin with an iPhone Xcode 4.2 project which will generate an iOS 5.0 static library. Our end result will be a static library which will be able to be linked to any iPhone app that wishes to provide an answer to this very question. Please open you copy of Xcode and follow along. I named my Project “HowManyEmcees” and created it as a static lib project sacked in my “dev” folder. (Feel free to save your project where ever you see fit.) Make sure you have the “Include UnitTests” checkbox marked and also check the “Create a local git repository” option to enable source control. For some it will be difficult but it’s very important that you follow each step exactly. The idea is to recondition yourself from writing code before you know why you’re writing code. Our first test will be as follows.

//
//  HowManyEmceesTests.m
//  HowManyEmceesTests
//
//  Created by Clifton Craig on 12/27/11.
//  Copyright (c) 2011 __MyCompanyName__. All rights reserved.
//

#import
#import "EmceeWarehouse.h"

@interface HowManyEmceesTests : SenTestCase

@end

@implementation HowManyEmceesTests

- (void)setUp
{
    [super setUp];

    // Set-up code here.
}

- (void)tearDown
{
    // Tear-down code here.

    [super tearDown];
}

- (void)testCanGenerateListOfEmcees
{
}

@end

We start by declaring the need for an “EmceeWarehouse” and beginning a test case that will eventually demonstrate how we get a list of Emcees from the EmceeWarehouse. That said, you can expect a warehouse full of emcees to get dissed in our example. Let’s continue with typical memory management etiquette assigning the warehouse in our setUp and clearing it in our teardown. (I could skip this step if I were to use the new iOS 5.0 ARC features but let’s keep things familiar and not introduce too much at once here.)

@interface HowManyEmceesTests : SenTestCase

@property (nonatomic, retain) EmceeWarehouse *emceeWarehouse;

@end

@implementation HowManyEmceesTests
@synthesize emceeWarehouse;

- (void)setUp
{
    [super setUp];

    self.emceeWarehouse = [[EmceeWarehouse alloc] init];
}

- (void)tearDown
{
    self.emceeWarehouse = nil;

    [super tearDown];
}

Now we hit Cmd+U, compile, crash, and understand that we need to actually have an EmceeWarehouse. It is very important that you compile at this point and verify all of the compile errors. If you are not getting compile errors then it is likely that you have not resisted the urge to correct the red flags in your editor as you went ahead and implemented the code before writing your test. If you don’t have errors, go back and delete your premature EmceeWareHouse, compile and crash. After crashing on compile create a plain old Obj-C object named EmceeWarehouse and add it only to the library (not the test) target. Compile, run (Cmd+U) and get your first green bar or passing test suite. (Why doesn’t Xcode unit testing feature green bars?) Back in our test method we express our intentions. This is the fun part because we can be as creative as we wish. I like to think of it as programming with the most dynamic language on the planet because you can change the way methods work as you write them without the penalty of recompiling or bug fixing. You’ll see what I mean in a moment.

- (void)testCanGenerateListOfEmcees
{
    id manyEmcees = [self.emceeWarehouse listOfEmcees];

    STAssertTrue([[manyEmcees class] isSubclassOfClass:[NSArray class]],
                 @"Expecting an instance of NSArray but got %@", [[manyEmcees class] description]);
}

Add the logic above to your test and compile, run and crash. If you didn’t crash you jumped ahead again. Delete your listOfEmcees implementation in “EmceeWarehouse.m” and start over. Note that the amount of code you delete and add later is directly proportional to the amount of unnecessary code found in projects that do not use TDD. As we iterate between test and code we are looking for the simplest thing that works which is the barest amount of code that can satisfy the most recent test, anything more will absolutely degrade the quality of your project. This will make more sense after a few iterations. Let’s look back at our test. It doesn’t quite fit what we are after. We are looking to get many different emcees from the warehouse, possibly all with varying skill levels. Lets change the test to make it more indicative of that.

- (void)testCanAskForManyDifferentEmcees
{
    id manyDifferentEmcees = [self.emceeWarehouse manyDifferentEmcees];

    STAssertTrue([[manyDifferentEmcees class] isSubclassOfClass:[NSArray class]],
                 @"Expecting an instance of NSArray but got %@", [[manyDifferentEmcees class] description]);
}

This contrived example illustrates an important point. Making changes to your tests should cost little if anything which highlights another valuable concept. Making changes to your product’s requirements should cost very little. In TDD, a test should be the direct result of a discussion of some product requirement and should closely follow or even echo a given requirement. Requirements change frequently because they cannot be completely understood until your product ages a little, so formalizing the requirements in test code is important. Also, if you are being penalized for changing your requirements then you will be less likely to make the necessary changes in your requirements thus suffocating your product. Now lets implement our warehouse just a little.

//  EmceeWarehouse.h
#import

@interface EmceeWarehouse : NSObject

-(id) manyDifferentEmcees;

@end

//  EmceeWarehouse.m
#import "EmceeWarehouse.h"

@implementation EmceeWarehouse

-(id)manyDifferentEmcees
{
    return nil;
}

@end

Cmd+U and crash! It’s like stumbling through a dark room with your hands extended reaching for the wall or nearby objects. We want to carefully approach our optimal solution without stepping passed it. The less code we use to solve a problem or requirement, the more power/flexibility we have to change existing requirements or add new ones. We need to make one minor change in “EmceeWarehouse.m” before we can move on.


-(id)manyDifferentEmcees
{
    return [NSArray array];
}

Now that we pass we can commit. Committing after every passing test is a good idea because it leaves a nice audit trail of how you grew your solution. One thing to note now is the return type of our method. Even though our test eventually compared the manyDifferentEmcees to an NSArray we didn’t formalize the return type in the method declaration. That optimization must be done after we go over the test a few times and get our initial pass because it allows us the time to mentally settle on the appropriate types. Once again, the barest amount of code to satisfy the requirement is what’s important. Then you go back and refine the requirements and finally the implementation. Looking back at our test we can ask ourselves, do we really want an NSArray or should it be an NSSet? Should we try to use an NSMutableArray? We’ll stay with NSArray since we probably want to go through emcees in a predictable order and also since each emcee will probably want to listen to the one before him. We’ll forgo the use of NSMutableArray externally because we don’t have a need to change the order or members of the array. That decision is difficult for some people because, as engineers, we like to expound on what we believe the optimal solution to be rather than allowing proper iteration to guide us. That is, we love to make those “experienced educated guesses” at what would most likely solve the problem. Making such assumptions (corruptions) is the actual equivalent of writing bugs into your software or pouring salt into the open wound. Let’s make the NSArray return type formal at this point run our tests to make sure they still pass and commit.

//  EmceeWarehouse.h
#import

@interface EmceeWarehouse : NSObject

-(id) manyDifferentEmcees;

@end

//  EmceeWarehouse.m
#import "EmceeWarehouse.h"

@implementation EmceeWarehouse

-(id)manyDifferentEmcees
{
    return [NSArray array];
}

@end

In our next requirement we explore how many emcees we’re prepared to devour. Recall above that we merely satisfied the requirement of being able to ask for emcees from the warehouse, now we need to count them and make sure we have enough to prove our street credibility. Pay attention to the fact that we are incrementally exploring what our requirements should be and using that to determine what code to write and how it should look. Add the next test.


-(void)testManyDifferentEmceesShouldIncludeMoreThanOne
{
    NSInteger howManyEmcees = [[self.emceeWarehouse manyDifferentEmcees] count];
    STAssertTrue(howManyEmcees > 1, @"Should have more than 1 emcee to prove street credibility. we count %i", howManyEmcees);
}

Compile, test, fail and fix the implementation to the simplest thing that works.


-(NSArray*)manyDifferentEmcees
{
    return [NSArray arrayWithObjects:@"This is not and Emcee",
            @"and neither is this",
            nil];
}

I like to push the needle towards stoopid sometimes as I add code that is obviously wrong. The point here is to force yourself to write the tests (or the “requirements” as I like to think of them) to expose the obviously wrong or missing code. We now have passing tests and an opportunity to commit. Commit the above changes and let’s move on to one of my favorite parts. Now it’s time to define what it means to be an actual “Emcee”. See the next code example.

-(void)testEachOfManyDifferentEmceesShouldBeAnActualEmcee
{
    for (id eachEmcee in [self.emceeWarehouse manyDifferentEmcees]) {
        //What do we do here???
    }
}

A heavy-handed approach would be to compare eachEmcee class against an actual class named “Emcee”. Since we haven’t thought that far in advance lets try something simple yet not so obvious.

    for (id eachEmcee in [self.emceeWarehouse manyDifferentEmcees]) {
        STAssertTrue([eachEmcee conformsToProtocol:@protocol(Emcee)],
                     @"How many emcees wanna be emcees? Never be emcees. Cause they can't emcee!");
    }

Protocols are mere abstractions that don’t need an implementation (similar to Java interfaces) and they are simple enough to allow us to specify our intention while allowing us to move on with developing the warehouse. I hit Cmd+U (you should too) after even the most minute source changes. It is a means of giving you instant feedback of what you did as well as how what you just did impacts the overall project. Our compiler (and our editor both) tells us we need to define the Emcee protocol. Now, towards the top of “EmceeWarehouse.h” add:

@protocol Emcee

@end

Cmd+U exposes the silly behavior in our warehouse. We need something that represents a real emcee so we’ll add the simplest thing that works. Put thins anywhere in your project (I included it at the bottom of “EmceeWarehouse.m”) to allow our test to pass:

@interface NSString(Emcee)
@end

@implementation NSString(Emcee)

@end

This is a category used only from within EmceeWarehouse.m so it does not need to have separate “.m” and “.h” files. I also like to patch up my implementation to reflect the new change:


-(NSArray*)manyDifferentEmcees
{
    return [NSArray arrayWithObjects:@"I wanna be an Emcee!",
            @"Now I'm an Emcee!",
            nil];
}

As you can see, right now it doesn’t take much to be an emcee. Make sure you commit your changes before moving on. Let’s make our warehouse just a little more interesting by including a capacity and making sure it’s always full to capacity.
HowManyEmceesTests.m

@interface HowManyEmceesTests : SenTestCase

@property (nonatomic, retain) EmceeWarehouse *emceeWarehouse;
@property (nonatomic, assign) NSInteger warehouseCapacity;

@end

@implementation HowManyEmceesTests
@synthesize emceeWarehouse;
@synthesize warehouseCapacity;

- (void)setUp
{
    [super setUp];
    self.warehouseCapacity = 100;
    self.emceeWarehouse = [[EmceeWarehouse alloc] initWithCapacity:self.warehouseCapacity];
}

Cmd+U crash with unrecognized selector “initWithCapacity:” sent to instance.
EmceeWarehouse.h

@interface EmceeWarehouse : NSObject

- (id)initWithCapacity:(NSInteger)aCapacity;
-(NSArray*) manyDifferentEmcees;

@end

EmceeWarehouse.m


- (id)initWithCapacity:(NSInteger)aCapacity /*we don't wanna do anything with the capacity yet!!!*/
{
    self = [super init];
    if (self) {
        //don't touch this part yet!!!
    }
    return self;
}

Cmd+U, pass, commit! Now we need to make sure we’re always full to capacity.
HowManyEmceesTests.m


-(void)testWarehouseIsFullToCapacity
{
    STAssertEquals((NSInteger)[[self.emceeWarehouse manyDifferentEmcees] count], self.warehouseCapacity,
                   @"EmceeWarehaouse should be full to warehouseCapacity");
}

Cmd+U fail, and fix:
EmceeWarehouse.h

@interface EmceeWarehouse : NSObject

- (id)initWithCapacity:(NSInteger)aCapacity;
-(NSArray*) manyDifferentEmcees;

@property(nonatomic, assign) NSInteger capacity;

@end

EmceeWarehouse.m

@implementation EmceeWarehouse
@synthesize capacity;

- (id)initWithCapacity:(NSInteger)aCapacity
{
    self = [super init];
    if (self) {
        self.capacity = aCapacity;
    }
    return self;
}

-(NSArray*)manyDifferentEmcees
{
    NSMutableArray *soManyDifferentEmcees = [NSMutableArray array];
    for (int countOfEmcees = 0; countOfEmcees < self.capacity; countOfEmcees++) {
        [soManyDifferentEmcees addObject:@"I wanna be an emcee!!"];
    }
    return soManyDifferentEmcees;
}

@end

Now when you have so many different emcees there’s bound to be a sucka in the mix! To be specific, a sucka emcee is the one that will cop out in the midst of a challenge. He’s the one that has no heart and is afraid to battle- the one emcee that’ll say “Don’t mess with Cliff”, thus terminating what eventually become an infinite loop, or never ending round of battles. Many people don’t understand what exactly does it mean to be an emcee. Our next round of tests will explain it very clearly. At the very bottom of “HowmanyEmceesTests.m” we’ll add:

#pragma mark - EmceeTests

@interface EmceeTests : SenTestCase

@property (nonatomic, retain) id theEmcee;
@end

@implementation EmceeTests
@synthesize theEmcee;

-(void)setUp
{
    [super setUp];
}

-(void)tearDown
{
    self.theEmcee = nil;
    [super tearDown];
}

@end

It’s more common to use different test case files but for our purposes we can stuff everything in one file. Hit Cmd+U and verify both test case classes show as being executed. (You can commit here as well.) Add our first definition of a real emcee:
HowManyEmceesTests.m

-(void)testAnEmceeCanBeASucka
{
    self.theEmcee.isSucka;
}

Cmd+U (after every little change, remember?) forces us to go add a property that will expose the true heart of each emcee, showing if he’s hardcore or not. (Yeah, yeah, I know! Our emcee could be a “she” as well! and she could also be hardcore.) Let’s define that property.
EmceeWarehouse.h

@protocol Emcee

@property (nonatomic, readonly) BOOL isSucka;

@end

Adding the following to the NSString category in “EmceeWarehouse.m” will eventually give us a warehouse full of sucka emcees:
EmceeWarehouse.h

@implementation NSString(Emcee)
@dynamic isSucka;

-(BOOL)isSucka
{
    return YES;
}

Cmd+U, pass and commit. We’re at a point where we should break out two different classes of emcees. Enter ChampionEmcee and SuckaEmcee, both of these will probably extend the base class of Emcee, right? Before we get ahead of ourselves let’s start from the tests since we have some cleanup to do. First create an empty file named EmceeWarehouse.m and cut/paste the following from “HowManyEmceesTests.m” (copy the imports of course but cut everything else):
HowManyEmceesTests.m

#import
#import "EmceeWarehouse.h"

#pragma mark - EmceeTests

@interface EmceeTests : SenTestCase

@property (nonatomic, retain) id theEmcee;
@end

@implementation EmceeTests
@synthesize theEmcee;

-(void)setUp
{
    [super setUp];
}

-(void)tearDown
{
    self.theEmcee = nil;
    [super tearDown];
}

-(void)testAnEmceeCanBeASucka
{
    self.theEmcee.isSucka;
}

@end

Commit after verifying that this new test case is associated with the tests target and its tests are still being executed. (In my case I believe it defatted to the test target since that was the active target.) Change #import "EmceeWarehouse.h" to #import "Emcee.h". Compile (Cmd+U), crash, and know that you now need to create and Emcee Objective-C file. Pay attention to how we always use the Cmd+U sequence to let either the compiler or the runtime let us know when we need to add more code. It is a difficult habit to build, breaking out of the “I know I need to do X” mentality. The more frequently you use Cmd+U the more you get used to seeing what doesn’t work while familiarizing with all the different errors that would otherwise confuse you. Add the new “Emcee” class and Cmd+U again to learn that you now need to move the protocol definition out of “EmceeWharehouse.h”.
EmceeWharehouse.h

#import "Emcee.h"
@protocol Emcee

@property (nonatomic, readonly) BOOL isSucka;

@end

Change the setUp to make sure we are exercising the Emcee class:

-(void)setUp
{
    self.theEmcee = [[[Emcee alloc] init] autorelease];
    [super setUp];
}

Cmd+U will show failure since we never declared/synthesized the isSucka property. Make the Emcee class follow the Emcee protocol and synthesize the isSucka property.

@interface Emcee : NSObject <Emcee>

@end

@implementation Emcee
@synthesize isSucka;

@end

Test (Cmd+U), pass and commit. Change the EmceeWarehouse manyDifferentEmcees method to use our new class and remove the ad-hoc category on NSString.

-(id<Emcee>)anyOldEmcee
{
    return [[[Emcee alloc] init] autorelease];
}

-(NSArray*)manyDifferentEmcees
{
    NSMutableArray *soManyDifferentEmcees = [NSMutableArray array];
    for (int countOfEmcees = 0; countOfEmcees < self.capacity; countOfEmcees++) {
        [soManyDifferentEmcees addObject:[self anyOldEmcee]];
    }
    return soManyDifferentEmcees;
}

Cmd+U, pass, commit. Now add the following to the bottom of the EmceeTests file:

@interface SuckaEmceeTests : EmceeTests

@end

@implementation SuckaEmceeTests

-(void)setUp
{
    [super setUp];
    self.theEmcee = [[[SuckaEmcee alloc] init] autorelease];
}

-(void)testASuckaEmceeWillAlwaysBeASucka
{
    STAssertTrue(self.theEmcee.isSucka, @"A sucka emcee will always be a sucka!");
}

@end

Hitting Cmd+U makes our toolchain inform us that we need to define a SuckaEmcee:
Emcee.h

@interface SuckaEmcee : Emcee

@end

Emcee.m

@implementation SuckaEmcee

@end

Hitting Cmd+U once more reminds us that a sucka emcee will always be a sucka. We must code our new class this way.
Emcee.m

@implementation SuckaEmcee

-(BOOL)isSucka
{
    return YES;
}

@end

Cmd+U, pass, and commit. Back in our EmceeTests class. We need to make our Emcees spit a lil’ sumn sumn.

-(void)testAnEmceeCanSpitSomething
{
    NSString *aLilSumnSumn = [self.theEmcee spitSomething];
    STAssertNotNil(aLilSumnSumn, @"aLilSumnSumn should never be nil because that's just not John Blaze. Y'know?");
}

Cmd+U makes us add the following:

@protocol Emcee <NSObject>

@property (nonatomic, readonly) BOOL isSucka;

-(NSString *)spitSomething;

@end

//And in our base class
@implementation Emcee
@synthesize isSucka;

-(NSString *)spitSomething
{
    return nil;
}

@end

Cmd+U shows two errors for the one test. This is important to pay attention to since we’ve added the expectation to the base test case for emcee it will apply to all Emcees, even the suckas. Add the simplest thing that works:

-(NSString *)spitSomething
{
    return @"I'll battle any sex or any race. You beating me is like Billy Crystal playing Scarface.";
}

That’s not necessarily the simplest thing but it’s colorful enough to get the point across. Now let’s see what happens when one Emcee spits something at another.

-(void)testAnEmceeCanSpitSomethingAtAnother
{
    id<Emcee> anotherEmcee = [[[Emcee alloc] init] autorelease];
    NSString *aLilSumnSumn = [self.theEmcee spitSomething:anotherEmcee];
    STAssertNotNil(aLilSumnSumn, @"aLilSumnSumn should never be nil because that's just not John Blaze. Y'know?");
}

Editor and compiler errors tell us we need to do something, something simple.

-(NSString *)spitSomething:(id<Emcee>)anotherEmcee
{
    return nil;
}

Cmd+U runs and shows us where we’re not so John Blaze. A simple fix would be to make the new spitSomething: work like the other.

-(NSString *)spitSomething:(id<Emcee>)anotherEmcee
{
    return [self spitSomething];
}

Now we’re going to see an Emcee just getting dissed.

-(void) testAnEmceeJustGotDissed
{
    [[[[Emcee alloc] init] autorelease] spitSomething:self.theEmcee];
    self.theEmcee.justGotDissed;
}

Cmd+U compile error tells us to add the missing method.
Emcee.h

@protocol Emcee <NSObject>

@property (nonatomic, readonly) BOOL isSucka;
@property (nonatomic, assign) BOOL justGotDissed;

Emcee.m

@implementation Emcee
@synthesize isSucka;
@synthesize justGotDissed;

Now add our expectation to our test case.

-(void) testAnEmceeJustGotDissed
{
    [[[[Emcee alloc] init] autorelease] spitSomething:self.theEmcee];
    STAssertTrue(self.theEmcee.justGotDissed, @"The Emcee just got dissed. Property check should confirm this.");
}

The simplest solution:

-(BOOL)justGotDissed
{
    return YES;
}

Of course it shouldn’t make sense. We want to write another test that explains why tour current solution is less than optimal:

-(void)testAnEmceeDidNotJustGetDissed
{
    STAssertFalse(self.theEmcee.justGotDissed, @"Nobody spit anything at the emcee. He did not just get dissed");
}

All along we are adding documentation along side our new software components. This is the best kind of documentation because it is executable and always up to date. When something breaks we have documentation explaining how we expect things to work and where the breakage is. Removing the formal definition from our implementation will cause it to fall back on the synthesized definition which will always return NO when we asked if we just got dissed. That will fix our latest test but break our earlier test. We are forced to change the state of the other emcee as we spit something at another emcee.

-(NSString *)spitSomething:(id<Emcee>)anotherEmcee
{
    anotherEmcee.justGotDissed = YES;
    return [self spitSomething];
}

//Remove/delete this...
//-(BOOL)justGotDissed
//{
//    return NO;
//}

Cmd+U to validate our above changes then feel free to delete the commented code. Cmd+U can be used to confirm our refactoring did not alter behavior prior to commiting. Congratulations! We have demonstrated how an emcee just got dissed. We’re almost there! A couple more changes are in order. First we need to elaborate on the SuckaEmcee. You see, a SuckaEmcee should say “Don’t mess with Cliff!” after he just got dissed because he’s soft. We need to add a test to document and demonstrate the idea. At the bottom of EmceeTests.m inside our SuckEmceeTests add the following:
EmceeTests.m

-(void) testASuckaEmceeJustGotDissed
{
    [[[[Emcee alloc] init] autorelease] spitSomething:self.theEmcee];
    STAssertEqualObjects([self.theEmcee spitSomething], @"Don't mess with Cliff!",
                   @"We expect the SuckaEmcee to be soft and tell others 'Don't mess with Cliff'.");
}

Notice how we really don’t need comments to explain what’s happening. Our expectations are inlined as code and our logic echoes our use cases. We can use the simplest thing that works here. At the bottom of Emcee.m in the @implementation for SuckaEmcee, we add this:

-(NSString *)spitSomething
{
    return @"Don't mess with Cliff!";
}

The SuckaEmcee feels slightly incomplete. We want our sucka to try to spit lil’ something on occasion, because he is an Emcee after all. The best way to demonstrate this is in our definition of an Emcee in the EmceeTests. We add a new test.

-(void) testAnEmceeWhoHasNotJustGotDissedWillNotShowFear
{
    STAssertFalse(self.theEmcee.justGotDissed, @"Given an Emcee that has not yet been dissed...(sanity check.)");
    STAssertFalse([[self.theEmcee spitSomething] isEqualToString:@"Don't mess with Cliff!"],
                  @"Any emcee will try to spit something before being dissed.");
}

Our test is showing us how our SuckaEmcee is not really behaving as an Emcee should. In plain slanglish, our current emcee is always punking out. We have to fix this since our sucka has “Emcee” in it’s class name and in it’s class hierarchy. In our SuckaEmcee @implementation we make it try to spit something before getting dissed:

-(NSString *)spitSomething
{
    if (self.justGotDissed) {
        return @"Don't mess with Cliff!";
    } else {
        return [super spitSomething];
    }
}

Cmd+U pass, and commit. Now there’s still an issue with the each Emcee in our EmceeWarehouse. Among every group of Emcees you’re bound to find a sucka. Lets add one more test to our HowManyEmceesTests to make sure.

-(void)testThereShouldBeASuckaEmceeInTheWarehouse
{
    NSUInteger locationOfSucka = [[self.emceeWarehouse manyDifferentEmcees] indexOfObjectPassingTest:^BOOL(id eachEmcee, NSUInteger eachIndex, BOOL *stop){
        return eachEmcee.isSucka;
    }];
    STAssertFalse(locationOfSucka == NSNotFound,@"Location of our SuckaEmcee should NOT be NotFound.");
}

Cmd+U and we see a new but expected failure from the assert we just coded. We need to change the implementation of our manyDifferentEmcees method using the most simplest approach:

-(NSArray*)manyDifferentEmcees
{
    NSMutableArray *soManyDifferentEmcees = [NSMutableArray array];
    for (int countOfEmcees = 0; countOfEmcees &lt; self.capacity; countOfEmcees++) {
        [soManyDifferentEmcees addObject:[self anyOldEmcee]];
    }
    [soManyDifferentEmcees addObject:[[[SuckaEmcee alloc] init] autorelease]]; //tack on a SuckaEmcee
    return soManyDifferentEmcees;
}

Cmd+U and guess what? We fixed our test and broke another. Our TestCases just deposited a few dollars into our development account! Our test, testWarehouseIsFullToCapacity, complains that our warehouse must be flu to capacity. We cannot just add a sucka on the end because he won't fit. For now we just tweak the manyDifferentEmcees method once again to make room.

-(NSArray*)manyDifferentEmcees
{
    NSMutableArray *soManyDifferentEmcees = [NSMutableArray array];
    for (int countOfEmcees = 0; countOfEmcees &lt; self.capacity - 1/* Leave room for desert, the last Emcee is gonna get ate!*/; countOfEmcees++) {
        [soManyDifferentEmcees addObject:[self anyOldEmcee]];
    }
    [soManyDifferentEmcees addObject:[[[SuckaEmcee alloc] init] autorelease]]; //tack on a SuckaEmcee
    return soManyDifferentEmcees;
}

At this point we've built enough infrastructure to answer our original question but this solution is a little boring and completely predictable since we always fill our warehouse with a sucka on the end. We have tests to cover our next move, refactor! We want to take a different approach to making sure there's a sucka emcee in the crowd. First restore our manyDifferentEmcees method to it's original form. Revert the EmceeWarehouse.m file so it looks like this:

-(NSArray*)manyDifferentEmcees
{
NSMutableArray *soManyDifferentEmcees = [NSMutableArray array];
for (int countOfEmcees = 0; countOfEmcees &lt; self.capacity; countOfEmcees++) {
[soManyDifferentEmcees addObject:[self anyOldEmcee]];
}
return soManyDifferentEmcees;
}

Cmd+U and fail on the original assert failure. Next we change the anyOldEmcee method to return either an Emcee or a sucka based on a random value:

-(id)anyOldEmcee
{
if ((arc4random() % 100) &gt; 95) {
return [[[SuckaEmcee alloc] init] autorelease];
} else {
return [[[Emcee alloc] init] autorelease];
}
}

That should give us a rough distribution of 5% sucka Emcees in our warehouse. We can adjust the percentage to our liking as our needs mature. For now this will do. Our last bit of code is intended to test each emcee. Create the following test case:

-(void)testHowManyEmceesMustGetDissed
{
    id cliff = [[[Emcee alloc] init] autorelease];
    NSUInteger locationOfEmceeThatJustGotDissed = [[self.emceeWarehouse manyDifferentEmcees] indexOfObjectPassingTest:^BOOL(id eachEmcee, NSUInteger eachIndex, BOOL *stop){
        [cliff spitSomething:eachEmcee];
        *stop = [[eachEmcee spitSomething] isEqualToString:@"Don't mess with Cliff!"];
        return *stop;
    }];
    STAssertEquals(locationOfEmceeThatJustGotDissed, (NSUInteger)0,@"%i emcees just got dissed", locationOfEmceeThatJustGotDissed + 1);
}

You may want to run this test more than once. It illustrates an important technique I often use when doing TDD. It’s what I call the discovery test. Whenever I have an API call that produces an unknown (or in this case variable) value that I want to discover, I write a failing test which outputs the value of the API call as part of the assert description. In the above example we finally discover how many emcees just got dissed, before somebody says, “don’t mess with Cliff!” I leave you to mull over it for a while. Leave comments if you will. G’night.

TDD- Is it worth it?


It’s been a long time, I shouldn’t have left you… without some strong code to step to. Step to, step too… step to… (Cliff re-quoting Timbaland re-quoting
Rakim…)

I’ve been attending a Srcum certification course led by none other than James Coplien. This guy is fantastic and I’ve already learned a great deal about the practice in the one day I’ve spent with him. Now here’s the controversial topic. Jim, is totally against TDD. If you know me, I am from the polar opposite camp. I had a breif dsicussion with Jim yesterday which I plan to continue today if he allows the time. In the interim I took the liberty of reviewing some of a standard email he sends to people like me who are unaware/unsure of his strong opposing position. The 1st link features Jim in a debate with a person I admire, Uncle Bob Martin from Object Mentor. This debate felt almost identical to my discussion with Jim yesterday and while both leave me unconvinced that TDD is harmful I remain open-minded. I am so open-minded to Jim’s position that I wanted to rush a quick post this morning to explain where I could potentially agree that TDD does more harm than good.

Testing at the wrong level

One of Jim’s primary arguments is that developers practice TDD at the wrong level, the class level that is not responsible for external features and contracts. This leads to code bloat from the test and gives you the wrong architecture from the onset. I whole heartedly agree with Jim on this point and it is something I still find myself doing from time to time. The practice requires a certain discipline and experience that you get only from making this and other similar missteps. In all, your design should come from your specifications or contracts and these should precede your implementation. I believe (without asking him) that Jim would agree with me here.

Poorly factored unit tests

One of the primary reasons TDD fails is because many miss the last R in the RGR cycle. RGR stands for Red Green Refactor. That means you write a failing test (reports red), make it pass (reports green), then you refactor both you system under test and your test code. I’ve made the mistake of not properly refactoring my test code in a hurry to move onto the next thing. Your test code should read like a contract or a usage guide for how to interact with your code. In practice the test code tends to grow rather quickly, which exceeds a developer’s ability to properly maintain it, which leads to the code bloat mentioned above. This step takes discipline and can be easy to neglect even for experienced developers.

Writing too much test or too much code

Following Uncle Bob, the TDD cycle is a tight and minimalistic cycle where you write only enough test to state or explore the current part of the specification you’re working on and only enough code to satisfy that test. Problems arise from writing too much test code without iterating over implementation code which is the inverse of YAGNI, YAGII! (You Ain’t Gonna Implement It.) Also you get into trouble from writing too much implementation code without a requirement or specification to justify it.  The power comes from the iterative approach to explorative development. As you iterate you uncover pieces of the spec that are not complete which might require discussion with your QA or business analyst and trigger discussions and that leads to an important distinction I’d like to mention. Many people make a distinction between bugs and features. I see them as one in the same. A bug is simply a non-feature or a hole in your spec. It represents some edge case or usage scenario that has not been explored which leads to errant unexpected or undefined behavior. You iterate on these the same as you do your features by amending your spec and filling in the holes in both the spec and your test cases which should mirror your spec.

I have to cut this short now since class is starting. It’s an interesting topic and I’d love to hear more about what Jim and others have to say on the topic.

TDD and the warm-fuzzy Un-learning curve…


I’ve been interacting with many more developers in my current company than I ever had in other companies over my career. One pattern I’m noticing is the warm/fuzzy philosophy. That is when somebody gets really comfortable with a certain way of doing things then you show them a new thing. Eventually they will find a way to use or associate the new thing with the way they always do things in order to get that warm/fuzzy feeling of, “it’s just like the other thing.” Hi, I’m Cliff. You’re here because you were probably looking for a product like Sham-Wow, Googled “warm fuzzy“, and clicked on a link to my crazy site. While you won’t find anything that sops up 32oz of Kool-Aid from your hard-woods after a three-year-old decided to play monster trucks on the kitchen table, you will get a lesson on how to forget what you thought you knew. Wait a minute, I forgot where I was going with this. You’ll get a lesson on why you should forget what you thought you knew. How to displace that knowledge is an exercise best left to the reader… (You, being that reader… you don’t get much exercise do you? Not with all the online reading and stuff.)

So when I talk to people and explain TDD (hereafter referred to as “the solution”) I usually get the response “it’s kinda like that system I used back at my other job only then we didn’t automate. We were just…”? Better? Honest? More careful? Clever? “Yeah back then we used to catch all of our bugs and…”? Re-fix them? Explain them as features? Double them? I occasionally get responses like, “you really don’t need to test first to get good code.” Let me ask a question. Have you ever seen good code? Chrysler 300 What does it look like? Does it where a tight-knit skirt and flirt from the corner? Does it come with a “HEMI” label, high RPMs, dual exhaust and chrome wheels? Is it tucked between two all beef patties, special sauce, lettuce, cheese, pickels, onions and a sesame seed… What does it look like, really?

What should it look like?
Call me crazy but I believe code (good, bad, ugly, and indifferent) should look like your spec. Do you know what your spec looks like? No you don’t! Because it just changed! Look again. There, it changed again! A decent spec is like a chameleon. It constantly changes colors, shapes, sizes. (For the record, chameleons don’t change shapes/sizes unless you put them in a blender. It has been proven that such a device, when activated, can render a chameleon very small and suddenly change both the size and appearance of the creature.) A poor spec is like a TV guide from 1976. It’s nostalgic to think about what was showing back then but of no use to anybody that wishes to figure out which station to tune to catch Judge Judy at 7:30EST. That is, a poor spec doesn’t tell you what you code should look like right now or what it should look like tomorrow. Did you catch that? I just explained that you need a TV guide to figure out what your code should look like tomorrow… not just any TV guide either. You need tomorrow’s TV guide, well, because it has tomorrow’s TV listings. Let that sink in a moment while I grab some coffee.

warm-fuzzy
Warm/Fuzzy
“Writing tests is like the ECMO system we had back at Rutherford And Son’s company. ECMO was the Enhancement/Change Management Officer in charge of each project. That person was a developer in charge of reviewing your code prior to commits and…” What was ECMO looking for? “We shouldn’t waste time futzing with tests… We just need to designate a [insert warm-fuzzy here]” What does any warm/fuzzy recreation of last year’s change management solution attempt to find? Defects, violation of practices, and unapproved system calls/libraries come to mind as common things to look for. What does any of this have to do with the spec? What does that spec look like again? “Who cares! We’re about to land some code, man! Plus we have approval for the EZ-Test framework which comes with new improved static analysis support.” (Ever wonder how new-improved some products really are?)

What Bad Code looks like
The unfortunate side effect of warm-fuzzy is that it fools you into believing that you’re creating good code. We all have seen Jeff Atwood’s Horror code examplesBad Code so there’s no question of what bad code looks like, right? Bad code has a smell. We don’t write no stinky code here because we have ECMO! (Trumpets blare to the sound of the Nightly News theme song introducing Brian Williams.) Warm-fuzzy overlooks an important but subtle point of the agile philosophy. Agile is not practiced to get good code, it’s a means of getting correct code. We’ll come back to that point in a moment. Let’s forget warm fuzzy for now. Let’s forget all we remember about ECMO. Let’s forget everything we were ever taught about good code, bad code, Dallas Cowboys and the Indiana Pacers.

The UnLearning Curve
Because technology constantly evolves our understanding of it must evolve. People learn things by association which makes picking up new technology and concepts a challenge. With technology you can flip a bit in a micro-processor and dramatically alter the flow of an application. Subtle changes can reveal brand new concepts that are completely disassociated with our understanding. (Try explaining the subtle change of a pointer variable vs. a regular variable which holds an address rather than a value to a Comp. Sci-101 student who only knows Java or VB.) In short, we have to unlearn to evolve. Remember the goto statement? An entire evolution of sub-routine evangelists had to scrub the planet and assassinate all other developers on the planet before “goto” finally got removed from modern languages. Believe it or not, there’s another similar revolution happening between those who do/don’t program with assignment statements. (Maybe one day they’ll remove the equals symbol from your favorite language… sounds far-fetched but so did dropping goto.) Those who lived by the word “goto” were hung up on it’s warm/fuzzy benefits so much that when you explained a subroutine to them they understood only to the point where it would return back to the caller. You truly had to changed your views/ideas/opinions on program flow and structured thinking in order to “get” subroutines. Simply stated, to learn new technology you often have to dis-remember old technology… the benefits in particular.

The Solution doesn’t care about good code
That’s a strong statement to make, but if you ask anyone who understands the true benefit of any philosophy from “the solution” they’ll tell you that it’s perfectly acceptable to use it with bad code. In fact, some may encourage you to write bad code in order to get a green bar. Better stated, instead of getting the code right you want to get the right code. If I pay you $50K for transportation what will you build me? A car right? Not just any car but a nice sports car with variable five speed transmission, anti-lock brakes, dual suspension and an auto-defog mirror. Nice! Good for you! I’ll go drive you’re treasured car into the ocean because I needed transportation to return to Jamaica and visit my long lost relatives. (What did your transportation spec look like again?) I would have been soo much better off with a shoddy rowboat than I’d ever be with my soggy car. Sure you got the transportation tool right. You even went as far as to pre-load my favorite MP3s. That’s how lots of people work because they’re stuck in “go” mode. Management says go! Get it done!

With software it’s soo much more dangerous because we can be creative and sorta dig ourselves out of the ocean. Many developers, after loading Method Man’s “Tical” to the in-dash mp3 storage, would eventually realize that the delivery date is approaching and maybe they should ask for a destination. I love it when we get to this point because that’s where the creativity truly begins. You might see fins under the tire, or a possible grappling hook that fires to attach to the complimentary aircraft – yet in design. Rarely and only in the most extreme cases does the car get dismantled.

To the left
The solution puts the focus on the left [consumer-facing] side of the code (which is why we lefty’s have so much fun with it!) The shape of the calling code becomes more important than the shape of what others refer to as “the real code”. It feels awkward because we think of ECMO. It feels redundant and slow because we already visited the left side of the equation. We know what we’re doing and we don’t want to waste time obsessing on the left side of the product. How many times should we keep asking “you want me to build you some transportation, right?” So to appease other people who obviously think it’s important, we ask a few more questions, like “where are you headed?” When we get a typical answer like, “far away to see my family” it further underscores the time wasted on the left. We then assume total control of the decision making process because our customer is clueless. “You’re obviously going to need dual overhead cam for speed since it’s so far away”, we think to ourselves. Many of us have gotten so good at it that we could literally assemble half the car before asking a third question.

I would continue my babbling but I have to cut it short because I’m off topic. The general idea is lost up there somewhere I’m sure. For all my people that understand where I’m going here speak out and nobody will care. Nobody will care because you’re expressing your opinion here rather than on Slashdot or Stack Overflow, or some other popular network. Here it’s just you, me, and the chickens… and the chickens have automated regression suites so we should listen to them instead. I now step down from my soap box and yield to the poultry.

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?