Java development with an iPhone touch pad for the Atari 2600 from an urban hip-hop perspective

TDD

I read a scripture this morning which shows clear evidence that God practices some form of Test Driven Design. Bear with me as it may sound non-obvious or one huge stretch. Just read Ephesians 1:4 NLT where it says:

Even before he made the world, God loved us and chose us in Christ to be holy and without fault in his eyes.

The key phrase is Before he made the world… That is before he wrote the code of humanity he chose us. Again, this may be counter-intuitive, but think about it. He chose us… he designed who we were to be before we existed. That is, he designed our outer interface or the blueprint for who we were to be in advance of implementing us. Y’all probably think I’m playing but I don’t kid around when it comes to scripture. This particular passage strikes me in a certain way as it’s the first I’ve read that clearly paints a connection from my faith to my coding practices. I’ve always known there was a pattern between what I study at church and the how I practice development but I couldn’t put my finger it. Then this passage jumps right out of the good book and describes the connection.

No long winded rant is necessary for tonight’s post, I believe the word says enough as it is written. Think about it.

“T” stands for Teddy! That’s good enough for me! Oh Teddy, Teddy, Teddy starts with “T”! Hi, I’m Cliff. You’re here because you wanna figure out what the heck that first sentence is talking about. I’m here because I got side tracked reading an Uncle Bob article which led to my singing a parody of the “C” is for cookie, Cookie Monster jingle. I’m STILL supposed to be working through negative password validation in an Android app but I don’t think I’ll finish in time for a planned demo in 2 days. You might ask “Why am I singing the letter ‘T’ when my title places emphasis on the letter ‘D'”? I’m glad you asked!

I’d like to tell you a story. Once upon a time there was a software engineer who ventured into the land of frogs where everything was green. It was like St. Patty’s day all time which was cool because this guy’s birthday happened to be in the month of March which is a green month. (I never understood why the month of March is always colored green. I suppose it has something to do with the Irish like they all came from Mars and make excellent landscapers or something but I digress.) So this developer *ahem* engineer was living in bliss because there were all of these segmented bars filling up in this magical land, each of which was green. He wanted to share the beauty of this whimsical place with his co-workers but they were all like, “Ain’t nobody got tahm of’ that!” So he goes on living in his shamrock colored habitat for the rest of his life. The end.

Now ask me why did I tell that story? (Again, I like how you ask questions!) Well partly because I sometimes feel compelled to inject random nonsense in the middle of my posts for no apparent reason. However the parody roughly represents my first encounter with TDD, a practice which I am extremely fond of. I want everyone to share in my euphoria but some folks are just wired different I suppose. It’s this wiring that causes some to focus on the wrong letter of the practice. Here we finally arrive at the point. By the way, welcome to the next entry in a series I’m titling “Stuff they taught in kindergarten”. In this series I will cover topics I just learn or re-learned. These are the very same topics my preschool teacher, Mrs. Marzie, covered during my early years. I missed out because I was busy fighting over who gets to play with the Green machine during recess.

“T” is for TESTING. As an avid practicer of TDD I will be the first to tell you that you should never write tests. If you are writing tests you are doing something wrong! When I practice TDD I never write tests or any test code. I hate tests. I despise the word “test”! Ask me how I could feel this way and still actually be a TDD supporter? I’m not a TDD supporter, I lied all this time. I’m a wolf in sheep’s wool. I support the practice but discourage the idea entirely. Let me elaborate.

The word “test” triggers the part of the brain that pulls you away from the most important part of TDD. Check the title to understand where I’m going here. I’ve seen so many well meaning engineers steer wrong because they start to get excited about tests and writing tests and testing their code. (Uncle Bob hits on this point somewhere in the middle of his article and I promised myself I would emphasize this point as the very first part of my blog but I’ve failed miserably!) If you are testing then you are looking for bugs. You are looking for holes in your code and weaknesses. All of this makes absolutely no sense because it implies you have working code. (I need to do an entire other post on the term “working code” because it’s another one of my pet peeves.) When you practice TDD the way it is intended then you don’t have working code. You don’t have broken code. You just don’t have code, instead you have a DESIGN. (Ah, there it is roughly 640 words in and I finally hit the point, design.) With TDD you have a design that you iterate into code that reflects a specific use case. It’s the emphasis on “testing” that turns people away from the discipline of designing. It is the discipline of design that gives TDD its power. When you practice TDD you never write tests, rather you etch a design using a testing framework.

Misconceptions
Before I get too far I want to address some misconceptions. In particular I need to disagree with one point Uncle Bob makes:

It’s true that TDD is not going to help you defend against things you didn’t anticipate.

Bob is well meaning and he wants to play nice with others but this is not entirely true. One of the major benefits of TDD is that you have the ability to incorporate use cases you didn’t anticipate into your design through loose coupling and better cohesion. Th most difficult thing you will ever do as a programmer is change code. When you encounter some use that was unplanned you have to make a change to your code to get it to adapt. If you don’t do TDD then I can guarantee that the change is going to cost more in effort than it cost to write the code initially. In many of these cases you build a work around to adapt to the new feature without actually changing the original behavior. If you do practice TDD then you have already established a predictable pattern of creating, changing, and removing code and the cost remains flat. That means it cost just as much to change existing code as it does to add new work-around code.

Getting back to what I said earlier, you don’t write tests with TDD. A test implies there is code with a potential flaw or weakness. With TDD you use a testing framework to express a particular use of code that has not yet been written. (That’s why it’s called “Test First” because you first code with the testing framework but you really aren’t coding a test you are coding the actual use.)

Another misconception:

the way to address that is to work hard at anticipating as much as possible.

I don’t know why people think working harder is the answer to tough problems. It is actually the cause of the tougher problems. If you are working hard at something then there is a flaw in the design. Also anticipating as much as possible is the opposite of what I like to do. I anticipate only what I feel comfortable anticipating and let the detail emerge as my project matures. As an example, I’ll use this Android app I’m currently building. I stopped working on it about 4-5 months ago and intentionally left holes in my design. I was only concerned about the app paths and getting a prototype working. I recently resumed the project and was able to easily cover some of these holes as I explored new unplanned uses of the code. When I originally wrote the code I just didn’t feel like anticipating these uses because they weren’t important. Now that many have become important I am able to address them with a fresh perspective and solve them in ways I wouldn’t have thought of earlier. Had I anticipated these uses I would have written code that would not be as flexible. It’s hard to describe actually. It’s one of those “you had to be there and live it” kind of moments.

I’m not picking on Uncle Bob… I love his writing/articles, and I’ve unfairly taken a couple of his points slightly out of context to drive a broader point. The point is that writing tests and testing code is not TDD. Designing the proper use of code before you implement it is the core of the practice. This is, by far, my biggest pet peeve with TDD and people who try to explain or defend it. I honestly think we should abandon the word test in favor of something more definitive like “specify”. I like the practice of Specification Driven Design where you specify how you will use/invoke an object with a test specification framework. Still its acronym, SDD, sounds too much like STD and could give the wrong idea. I wouldn’t want to announce I am giving a class on SDD or tell folks I got this SDD thing at work. They’d be all like, “fo’ realz??? Yo, keep ya’ distance!”

That’s all for this installment of stuff they probably taught in kindergarten. I’ll see you next time I get inspired to blab about something.

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:

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:

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:

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?

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:

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:

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:

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.

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!

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.

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.)

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.

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.

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.

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.

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.

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:

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

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:

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

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

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

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 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.

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.

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

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:

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.

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.

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:

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:

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.

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.

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? 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
“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 examples 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.