Code Retreat GR Recap

Jeremy Anderson — Wed, 17 Feb 2010 22:12:01 +0000

On February 6th I hosted the first Code Retreat to hit West Michigan, and we really couldn’t have asked for a nicer day for a Code Retreat. Well, maybe a little bit warmer weather, but hey, it’s February in Michigan, what do you expect? So after a quick stop at Panera Bread to get some bagels, scones and muffins, I made my way down to Atomic Object HQ to start the coffee brewing in preparation for the attendees. Shortly after sunrise, Nayan Hajratwala showed up to help with any last minute preparations before everyone else showed up.

Soon about 20 people from all parts of the region had showed up to practice TDD and learn with each other, including one guy who came all the way down from Marquette, MI just to attend. He officially got the “I traveled the furthest” award for the day. We were also joined by Ron Jeffriesand Chet Hendrickson, who had agreed to come and be my professional trouble makers for the day. Shortly after 9:00, once everyone had been sufficiently caffeinated, we decided to get started. One of the attendees had mentioned something about Corey Haines putting together aset of Cucumber features at one of the previous Code Retreats in Chicago, so some of the pairs decided to give that a whirl. After some yak shaving we managed to get through the first iteration of the morning and retrospected on what happened and continued on into the second iteration of the day.

My original plan was to just sort of float around, help facilitate, and observe everyone else pairing, however when I noticed Ron Jeffries didn’t have a pair for the second iteration, I took the opportunity to pair with him. Neither of us knew Cucumber very well, so we decided to give that a whirl. If ever you get the chance to pair with either Ron or Chet, don’t think twice about it, just do it. Ron had at one point in the day managed to – as one participant described “…[kick his] BDD mindset a bit out of place. . . “

Before we knew it, lunch was upon us. It turns out that Corey Haines was hosting another Code Retreat in Seattle that day, so we fired up Skype and greeted our fellow Code Retreaters on the west coast as they were just getting ready to start for the day. Then we all proceeded to enjoy the taco bar that had been delivered for lunch and continued to retrospect on the days events so far. When we were all finished stuffing our faces with Qdoba, Mike Sweiton and myself gave our participants a quick tour of Atomic Object HQ, showing off our open space, stoplight, CI server, and our embedded projects workbench.

Now that our food had a chance to settle, it was back to pairing for a few more iterations of Conway’s Game of Life. After one of the afternoon retrospectives, for a little bit of a distraction, we watched a video of someone implementing Conway’s Game of Life in APL. This was spawned by an email thread that circulated right before the Code Retreat about how to implement theGame of Life in a single line of APL, which still blows my mind.

Finally, by the time the end of the day had finally arrived, we had lost a few of our fellow coders and we were ready to call it a day. Those of us who were still left standing at the end of the day took a walk around the corner to The Green Well, one of the many local establishments in the Eastown area, for some much needed unwinding. We continued to retrospect on the day’s happenings over a few local microbrews and some delicious items from the menu. All in all I would have to say this was a successful Code Retreat. Everyone had a great time, we all got to pair program with some great folks we wouldn’t normally get to pair with, and – most importantly – learning happened. Though many of the Code Retreats in the past have used Java as their language of choice, in my opinion I think using Ruby for this Code Retreat was the right choice. It afforded us much less yak shaving than would have probably been necessary had we been using Java. I’m looking forward to hosting another Code Retreat later this year when the weather is a little warmer, and hopefully attending the upcoming Code Retreat being hosted in Philadelphia by Sebastian Hermida.

Tagged: agile, code retreat, craftsmanship, cucumber, kata, Ruby, tdd, test first, testing, unit testing

Unit Testing JSP Custom Tags

Jeremy Anderson — Fri, 25 Jan 2008 13:43:40 +0000

Testing J2EE components has always been a difficult task, which is probably why I see so many web projects that have few tests written for the web layer or sometimes none at all. Late last year Spring announced the release of Spring 2.5 , with some nice additions to the suite of mock testing objects for unit testing web components. That’s right unit testing web components, not in container testing. So like any good agile programmer let’s start with the test first.


public class SomeCustomTagTest extends TestCase {

    private SomeServiceInterface mockService;
    private SomeCustomTag someCustomTag;
    private MockServletContext mockServletContext;
    private MockPageContext mockPageContext;
    private WebApplicationContext mockWebApplicationContext;

    protected void setUp() throws Exception {
        super.setUp();
        // Create the mock servlet context
        mockServletContext = new MockServletContext();

        // Create the mock Spring Context so that we can mock out the calls to getBean in the custom tag
        // Then add the Spring Context to the Servlet Context
        mockWebApplicationContext = createMock(WebApplicationContext.class);
        mockServletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
                                        mockWebApplicationContext);

        // Create the MockPageContext passing in the mock servlet context created above
        mockPageContext = new MockPageContext(mockServletContext);

        // Create the mock service object using it's interface
        mockService = createMock(SomeServiceInterface.class);

        // Create an instance of the custom tag we want to test
        // set it's PageContext to the MockPageContext we created above
        someCustomTag = new SomeCustomTag();
        someCustomTag.setPageContext(mockPageContext);

        // Whenever you make a call to the doStartTag() method on the custom tag it calls getServletContext()
        // on the WebApplicationContext.  So to avoid having to put this expect statement in every test
        // I've included it in the setUp()
        expect(mockWebApplicationContext.getServletContext()).andReturn(mockServletContext).anyTimes();
    }

}

Some things you’ll notice in the setUp() method are that we’re creating a mock for the Spring Context. Since I don’t know of any way to have Spring inject dependencies into the custom tag, we’ll be getting a WebApplicationContext object from the container to get our beans from Spring. This mock allows us to fake calls to getBean() and return our mock service objects so we can unit test the custom tag without relying on external dependencies.
Now in order to get this test to compile we need to create the custom tag class. You’ll notice that we’re extending the RequestContextAwareTag class instead of TagSupport. The RequestContextAwareTag class is a Spring helper class that gives us some convenience methods for getting the WebApplicationContext among other things. You’ll also see that the method we need to implement is called doStartTagInternal() instead of doStartTag().


public class SomeCustomTag extends RequestContextAwareTag {

    protected int doStartTagInternal() throws Exception {

        // put some business logic here

        return SKIP_BODY;
    }

}

Now let’s write a failing test. Back in the unit test lets add a test method and a couple of helper methods for the mock objects.


public void testDoStartTag() throws Exception{
    String param = "Jeremy";
    String expectedOutput = "Hello, " + param;

    replayAllMocks();

    someCustomTag.setUserName(param);
    int tagReturnValue = someCustomTag.doStartTag();
    String output = ((MockHttpServletResponse) mockPageContext.getResponse()).getContentAsString();

    assertEquals("Tag should return 'SKIP_BODY'", TagSupport.SKIP_BODY, tagReturnValue);
    assertEquals("Output should be 'Hello, Jeremy'", expectedOutput, output);

    verifyAllMocks();
}

private void replayAllMocks() {
	replay(mockWebApplicationContext);
	replay(mockCompanyQuery);
}

private void verifyAllMocks() {
	verify(mockWebApplicationContext);
	verify(mockCompanyQuery);
}

In order to get the test to compile, you’ll need to modify the SomeCustomTag class to have a setter method for a userName parameter. We would like our custom tag to say “Hello” to a username that is passed in, so let’s implement the behavior we are trying to accomplish.


public class SomeCustomTag extends RequestContextAwareTag {

    private String userName;

    // A setter for an attribute that will be set in the custom tag
    public void userName(String userName) {
        this.userName = userName;
    }

    protected int doStartTagInternal() throws Exception {

        pageContext.getOut().print("Hello, " + userName);

        return SKIP_BODY;
    }

}

Next we would like to get the users full name from our Spring service. So in order to do that we need to tell the mockWebApplicationContext to return a mock of our service so we can unit test this in isolation. We also need to tell our mock service that we expect a call to getFullName() and what to return from this call. So modify our test method to resemble the following.


public void testDoStartTag() throws Exception{
    String param = "Jeremy";
    String fullName = "Jeremy Anderson";
    String expectedOutput = "Hello, " + fullName;

    expect(mockWebApplicationContext.getBean("someService")).andReturn(mockService);
    expect(someService.getFullName(param)).andReturn(fullName);
    replayAllMocks();

    someCustomTag.setUserName(param);
    int tagReturnValue = someCustomTag.doStartTag();
    String output = ((MockHttpServletResponse) mockPageContext.getResponse()).getContentAsString();

    assertEquals("Tag should return 'SKIP_BODY'", TagSupport.SKIP_BODY, tagReturnValue);
    assertEquals("Output should be 'Hello, Jeremy Anderson'", expectedOutput, output);

    verifyAllMocks();
}

Now when you run this code, you’ll get an error from EasyMock complaining about methods that were expected to be called, but weren’t. So lets fix that now. Modify the doStartTagInternal() method to look like the following.


protected int doStartTagInternal() throws Exception {
        // Get the Spring Context from the RequestContext
        WebApplicationContext context = getRequestContext().getWebApplicationContext();

        // Get the service we want to call from the Spring Context
        someService = (SomeServiceInterface) context.getBean("someService");

        String fullName = someService.getFullName(userName);
        pageContext.getOut().print("Hello, " + fullName);

        return SKIP_BODY;
    }

Congratulations, you’ve now implemented a JSP Custom Tag using “Test First”.

Code Adept » test first

Code Retreat GR Recap

Unit Testing JSP Custom Tags