Test Driven Development

How to develop Micro-ISV software.

If you’re going to successfully fire up your micro-ISV, you need to fire your old ideas about software development, be they UML, RUP, agile, SCRUM, extreme or none: they fit like shoes on fish.

Every single methodology for developing software I’ve heard of in over 20 years in this business assumes you’re part of some vast team of programmers, never a programmer working alone. What’s more, each and every existing software development process assumes someone is going to hand you a nice gift-wrapped definition of the problem you’re going to solve via code. That is exactly what won’t happen when it comes to developing a micro-ISV app or web site.

Today’s software design theories are like using a power drill as an ear cleaner - they can be used, but it’s not a good idea. We need a better approach, one based in the reality of one or maybe two programmers who must also define the problem and its solution and who want to do so before their savings run out.

Don’t underestimate just how hard defining the problem domain is, or just how difficult it is to nail down in the absence of actual customers who will tell you what they want. Unless you plan to take a few years unpaid leave from your life to do intensive market research, endless focus groups and surveys, at best you are only going to have a very approximate idea of who is going to be using your software how to solve exactly which problem in what precise way at least all the way through to your public beta.

Planning your virtual future

If you've not been bitten by the Virtual Machine bug yet, it's time to give virtualization, and especially VMware your attention. VMware is out to change a few things in this world, one being how servers serve and the other how developers develop.

I Spec, You Spec, We RSpec!

I love testing, I could hardly wait for this meeting of the Chicago Ruby Group. I was not disappointed. Unit tests are cool, but specs are awesome. Whats the difference you say? I think its a more natural way to write your tests, it makes you think of the behaviour of your object and not "oh gosh, I have to write 3 tests for each of my methods."

Testing with Selenium TestRunner

I know, I know its been two weeks since I posted. . . but I hope this makes it worth the wait!

I've looked at Selenium a few times but just couldn't fathom how it could possibly work -- and with all javascript?? I went to a Ruby "HackFest" here in my beautiful city of Chicago and met one of the developers of Selenium , Jason. He gave a demonstration of Selenium testing itself and I saw how it worked, but how do I get it to work? As it turned out, in my traditional fashion, I was making it harder than it really was.

Ahhh-tonomy

Wow, what a productive week!

No, I'm not kidding. I'm on fire, kids. Just having a good week, cranking out lots of good, working code. I've been kickin' ass and chewin' gum, and I'm almost out of gum. You know how it is: sometimes you're on and sometimes you're not. This week I was on.
Something I'm feeling good about: I have a large degree of autonomy on my latest project. I gathered a pile of requirements and went to town. Just for kicks, I decided to try a development approach I've read about but never got to try in a production environment: refactoring to patterns.

For those of you who are old hands at this, accept my apologies, stop reading this, and go watch Arrested Development instead. The rest of you, if you're still awake, finish reading, then go watch A.D.

Test Cases

When unit testing, there seems to be two ways to go about writing a test suite:

Case 1 (One assertion per case):

Testing is Important

Reading a quoted entry over at DeveloperTesting.com:

I have been consulting for a number of teams that have adopted Agile Methods, including TDD. One common issue I have found is that developers drop the discipline of TDD in the face of schedule pressure. "We don't have time to write tests" I hear them say. Before I comment on the absurdity of this attitude, let me draw the parallel. Can you imagine an accounting department dropping dual entry bookkeeping because they've got to close the books on time? Even before SARBOX such a decision would be such a huge violation of professional ethics as to be unconscionable. No accountant who respected his profession, or himself, would drop the controls in order to make a date.

I completely agree with the above sentiment. However, the notion that developers are absurd for acting this way is, itself, a bit absurd.

Book Review: Java Extreme Programming Cookbook


Since I've been talking about Unit Testing quite a bit recently, I thought I'd offer up a review on a book I read a while back. I thought it was a solid roundup of both the principles and the tools used to support Extreme Programming in Java. Overall, I'd give it a 9/10 and I deduct a point solely due to the fact that since it details the usage of numerous Open Source projects, it's halflife could be very short. Regardless, this is more than enough to get you started and will teach you the basics to be able to do even more interesting things.

Just to make this clear right off the bat, if you're not working in Java, only pages 11-27 are going to be of any use. These pages go over the different pillars that make up Extreme Programming (XP). Whether you're using XP or not, you can pick and choose the pillars you need and customize them to your project pretty easily. The principles are: Pair Coding, Unit Testing, Refactoring, Iterative/Minimal Upfront Design, and Regular Builds. I have yet to see a project that cannot benefit from having Unit Testing and Regular Builds in place. These two items serve as a great safety net for current and future development efforts by detecting errors soon after insertion.

I love Unit Testing

Alright, so I admit that I'm completely biased. I can't be impartial about it and I don't think you should be either. Once you begin writing Unit Tests - or better yet Test Driven Development - you don't want to go back. Once you have a series of Unit Tests for a particular class, method, etc, it's painful and scary to modify code lacking these tests...

But I also see the value in Unit Testing in a few other areas.

Enemy Unit Testing

I'm a big advocate of Agile Methods and principles. I believe quite simply that an evolutionary design, refactoring, user stories, and especially Unit Testing. So when I came across the concept of Enemy Unit Tests, I was dumbstruck by the logic of it.

Think about it. When we right code, we write Unit Tests (hopefully!) and run them as often as necessary. You may not run all of them all the time, but you run the important ones as often as possible.

Now what about all those libraries you're using? When was the last time you tested those?