Sometimes technical folks selling enterprise software can be so very honest. We had an IBM architect, of which they have many, mention in a presentation on SOA admit:

“This is not easy stuff to implement. You got a Ferrari but it came in boxes and pieces.”

I don’t know if we got a Ferrari. Considering we bought the Websphere solution based on feeling safer with a large application platform vendor versus going with a best of breed type solution, I doubt it will ever turn into a Ferrari. I’d settle for a Ford Taurus that actually did something out of the box.

And the bit about not being easy to implement, no kidding. As software development is swinging towards greater simplicity with open source frameworks, dynamic languages making a comeback, and even J2EE slimming down with EJB 3.0, enterprise vendors are still pushing complexity.

One unexpected bonus of implementing TDD in our shop came up this week. Mocks can be a development tool as well.

The situation is pretty simple, our legacy development environment is down. Since it is our main data source on the project in the past this would have left the team dead in the water. Turns out they’ve mocked all of the DAOs that return some predetermined data using Spring. No developer downtime at all. Of course they can’t turn over the current new code for testing by QA against the real legacy system, but at least they can continue on without interruption. They didn’t even really mention the mainframe environment being down as an impediment in the daily Scrum.

So mocks have come in handy not just for a lot more than enabling unit testing. If you have to depend on some flakey resource they can be a lifesaver.

You don’t come across a developer job posting quite this creative all that often (courtesy Cory Foy via the XP mailing list). I love the idea of doing a code based job posting, but I’m not sure you could swing it by your average Fortune 500 HR department.

My personal favorite statement:

assertTrue(candidate.practiceTDD());

And my favorite method, that I think is too often overlooked in really good candidates is:

public void testTeachingSkills() {
  assertTrue(candidate.canImproveTeamSkills());
  assertTrue(candidate.canArgueAboutAgility());
}

Since as soon as you add login to a site your functional tests are going to require a login, there is of course an easy fix documented here. You just add a login method to your test_helper.rb file. Then you call it in your setup method:

def setup
  @controller  = LoginController.new
  @request     = ActionController::TestRequest.new
  @response    = ActionController::TestResponse.new
  login
  @controller  = AdminController.new
end

I made a silly mistake at first and called

right after:

@controller = LoginController.new

Of course I was greeted with a whole bunch of:

RuntimeError: @request is nil: make sure you set it in your test's setup method.

Simple fix was to move it after the creation of the request and response objects needed by the

method. At least the error message made it a quick duh! moment.

Dave Astels argues pretty strongly that though Test Driven Development is catching on, many people could still be practicing it better. One issue is the idea of one-to-one production classes to test classes:

“A lot of people have a mantra. We’ll have ClassX and ClassXTest.”

– Dave Astels

His point is well taken, and honestly I often fall into the trap of doing approximately one-to-one test to production classes. The brilliant advice is to:

“Have lots of little test classes. Should be building test classes around the setup or fixture that your building. That gets you a long ways towards BDD (Behavior Driven Development).”

— Dave Astels

So a code smell when writing unit tests is that you have tests that depend on the setup and tests that don’t use it or depend on another setup. This is a sign that you’re not testing just one behavior and you should refactor things out to two test classes.

A very simple idea, but very easy to recognize while you’re coding. (This advice comes from a talk he gave at Google, but its a very enjoyable talk for about 45 minutes on BDD)