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)

As a manager I had a proud moment on Friday at a regular standup meeting. Everyone went around the room as usual and since it’s nearing the end of the sprint, the testing members pressed on when the code would be ready in QA to start formal testing. The developer responded:

“We’ll be done Wednesday, like we said.”

The scrum master chimed in with:

“Well, could be be done Tuesday afternoon, or how about Wednesday morning?”

Again the developers responded:

“We’re going to be done by the end of the day Wednesday. That still gives you four days to test before the end of the sprint. It won’t be done until the late Wednesday because we still have a whole JSF page, backing bean, service, DAO, and unit tests to write. On top of that RAD is crashing on us all the time.”

The scrum master responded:

“OK, I was just checking to see if we had some wiggle room, sounds like we’ll test starting Thursday morning.”

I’ve been coaching my developers to always keep in mind everything they have to do including unit testing and refactoring and not to compromise quality when the push comes to get things done faster. Here was an example of a developer really standing up and asserting that they weren’t going to rush it and cut corners.

Stumbled my way through leading a Sprint review for our Intranet Portal project. I felt a bit unprepared as I hadn’t even bothered to make nice slides of the 14 product backlog items we completed. (I just read off the 3×5 index cards I pulled off our Sprint board that morning) To top it off I hadn’t checked the site the day before and it turns out the search feature still wasn’t working as we hadn’t set the indexing spider off crawling the site. Whoops, that was part of our Sprint goal.

Still the review went remarkably well for one primary reason. We finally had the product owner, an editor in our Communications department, drive the actual review. The buy-in you get when your customer actually drives the demonstration is priceless. I hadn’t experienced this on one of our projects, because I’ve never gotten to run a Scrum project officially. The business owners have continued to largely follow our broken waterfall methodology and we’ve just run the project as a Scrum project sans a participating project owner.

To top it off the product owner had only worked with Websphere’s Content Management system for a few days and suffice it to say it is quirky and a poor example of software usability. The fact that he did a fine job of adapting to it gives us more faith that we’ll have some luck rolling it out to 30 or so content authors across the company, given a healthy dose of training and support.

The other nice side effect is the team is gelling a lot better now than when we started two months ago. An earlier attempt at getting the intranet relaunch ended with the customers and the developers at almost polar opposites and truly distrusting each others motives. In two short months we’ve been able to repair things and we’re collaborating again, not fighting pitched battles over how many colors to use on each page.