What I Learned Programming With the Stars

I had a great experience pairing with Patrick Wilson-Welsh at Programming with the Stars at Agile 2009 in Chicago. We were ousted in the first round but we had a blast. And I learned a few things along the way:

You should make your tests expressive

We were deducted points for not including the word “should” in our tests. I do strive for this but find that this “rule”, as with any rule, can be too restrictive. Liz Keough suggests that the word “should” should be the first word in your test method name. Getting tired of the word “should” yet?

I strive for expressive test method names that clearly state a design criteria for the class under test. So my preference is to make the test method name a full sentence. And of course I try to include the word “should” in it. Using this approach I find it hard to craft a test name beginning with the word “should” that reads like an assertion rather than a question. So, I rarely start my tests with the word “should”. Also, I break from production code styling and use underscores so that test method names are as readable as possible:

As Brian Marick would say, “an example would be good right about now”. So, if we have a test like this:

  1. @Test
  2. public void handleZero() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

Then a refactoring like shown below provides a more expressive test:

  1. @Test
  2. public void zero_should_be_closer_to_zero_than_any_other_integer() {
  3.     assertEquals(0, Closest.closestToZero(new int[] {0,2,4}));
  4. }

Don’t write new conditional production logic without a new failing test

Jim Newkirk deducted a point because we added an ‘if’ statement without a new failing test. This was new to me although it makes perfect sense and I appreciate the insight from Jim.

So, if you are about to write new conditional production code without a new failing test … stop! If you are currently trying to make an existing test pass then try to get it to pass without a conditional statement. Otherwise, update the test so that the new conditional logic is not required. Once you get green with this you should then write the failing test that will require the conditional logic you were about to add. Now, you can add the conditional logic sufficient to get the test green.

You can’t write much code in 3.5 minutes

Patrick and I were test-driving a method that would return the integer that was closest to zero in an input array. We knew from writing the initial code and refactoring it what a clean code implementation could look like. And, as if often the case, the refactored code looked obvious in hindsight. We decided that given the time restrictions we would write our initial code towards the refactored code as it reflected an intentional programming approach. Bad idea, we were deducted points for thinking too far ahead and then not having any significant refactoring.

So, if you are in this position, write some really, really simple code and allow time for simple refactoring … and let intentional programming code emerge from the refactoring.

Don’t go first

Just sayin’ …

Hanging out with agile journeymen is mental adrenalin

Having an opportunity to talk code with people like Liz Keough, Jim Newkirk, Brian Marick and some top-notch agile coders was a real buzz. Hanging out with Patrick Wilson-Welsh and the cool Pillar dudes was also a blast. If you get a chance sign-up for this at Agile 2010!

Many thanks to Joshua Kerievsky, Jeff Nielsen and Industrial Logic for sponsoring this event.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • StumbleUpon
  • Reddit
  • Facebook
  • Google Bookmarks
  • Slashdot
  • Technorati

5 Comments

  1. Patrick Wilson-Welsh:

    I agree with Declan’s summary on nearly all points. I don’t think our intentional programming idiom was in any way incorrect; we just ran out of time.

    I think Newkirk’s objection was most useful and legitimate.

    I agree with Newkirk that if every test method name ends up including the word should, then the word should ends up becomming noise. BDD semantic preferences and obvious superiority notwithstanding.

    I had a blast with you too, Declan!

    3.5 minutes is way short. Too short for us to swap keyboards, which would have earned us points back, I think…

    –Patrick

  2. Llewellyn Falco:

    Here’s a 3 minute solution to closest to zero.
    It doesn’t handle newkirk’s objection, except to ignore using an if statement.
    And it’s a bit different than what most people do, but it’s what I would actually do, it’s fast, and gives me the important parts I want from test first, namely:
    specification
    feedback
    regression
    & granularity

    I feel somewhat that people have forgotten that we use these practices to help us go faster.

    public class ClosestToZeroTest extends TestCase {
    public void testNumbersSort() throws Exception
    Integer i[] = { 0, -1, 3, -4, 80, -80 };
    sortAbsolute(i);
    Approvals.approve(“”, i);
    }

    public void testNumberNearZero() throws Exception {
    Integer i[] = { 2, -4, 80, -80 };
    assertEquals(2, getLowestNumber(i));
    }

    private int getLowestNumber(Integer[] i) {
    sortAbsolute(i);
    return i[0];
    }

    private void sortAbsolute(Integer[] i) {
    Arrays.sort(i, new CloseToZero());
    }

    public static class CloseToZero implements Comparator {
    @Override
    public int compare(Integer a1, Integer a2) {
    return Math.abs(a1) – Math.abs(a2);
    }
    }

    }

  3. Twitted by dwhelan:

    […] This post was Twitted by dwhelan […]

  4. dwhelan:

    Llewellyn,

    The use of Approval Tests is interesting. I will have to try it out! Also, using the Comparator with Arrays.Sort is a simple solution. Thanks for suggesting it!

    Declan

  5. Agile 2009 Post Roundup | Agile Pain Relief:

    […] What I Learned Programming With the Stars and Building a Learning Culture on Agile Teams (Slides) – Declan Whelan […]

Leave a comment

*