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.

So to get to the point, now that I’ve had some time to look at the tool, I’m rather pleasantly surprised.  I’ve seen this tool in action, and generate a bunch of integration tests for a service layer for an application, which will allow you to refactor confidently.  Jump over to the website (http://frogyourcode.com) and check it out.

In 2002 Macromedia used the term “Rich Internet Applications” (RIA) to describe the next generation of web applications that have all of the benefits of a traditional desktop application, with the flexibility of being deployed via the Internet.

However, it’s 2008 and RIA has not been able to penetrate the business application sector with any real success. The old days of RIA are history. (Maintenance nightmares, weird or no unit testing, and little friendliness toward other agile developer practices.)

With a RIA framework like Adobe Flex it’s now possible to unit test RIA applications and even write tests first. It’s possible to connect up to a CI server just like server-side code and pick up coverage stats. It’s possible to evolve a simple design incrementally and emergently.

The speakers will model how to make standard agile development practices work in the RIA world: Refactoring, Test First Design, Simple Design, Continuous Design, and Continuous Integration & Automated Builds.

The bottom line is many businesses have invested much time and money into their existing applications and their staff. For this reason, this session will guide the attendees on how to refactor an existing web application with familiar server-side technologies. We’ll show how to integrate Flex into existing applications in order to build a next generation application that will delight users.

Rather than trying to teach the basics of Flex, the speakers will demonstrate how to develop robust applications leveraging the Flex framework in concert with enterprise technologies like Java. These applications can be deployed not only to the web but also to the desktop using the Adobe Integrated Runtime (AIR).

 

Process/Mechanics

 

Refactoring to RIA’s will be a demonstrative (tutorial-like) session geared towards Java developers that would like to refactor existing applications in an agile way. Test First, CI, and other friendly agile practices will be key in making this possible.

The session will consist of live code and practice demonstrations leveraging an already existing application. Requirements for creating a new rich client interface will be explored and code will be refactored in a Red/Green/Refactor manner.

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();
    }

}

public class SomeCustomTag extends RequestContextAwareTag {

    protected int doStartTagInternal() throws Exception {

        // put some business logic here

        return SKIP_BODY;
    }

}

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);
} 

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;
    }

}

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();
}

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;
    }

So I’ve decided to start a Google Code project called agile-flex, where a couple of other developers and I will attempt to build some agile tools for the Flex framework, starting with a test runner that will help enable continuous integration for Java, .NET, or even just plain old Actionscript. The runner will likely be based off an article I found from Aaron Spjut here. In a nutshell we will create a test runner in Adobe AIR that will generate XML output similar to JUnit and NUnit for the CI server to be able to interpret. This will also enable the generation of report artifacts using the JUnit Report tasks or even a custom XSLT if desired. I’ll post more details as the project continues.

UPDATE… The Flex-Mojos project now fulfills this need, so I’ve deleted the Google Code Project that we started for this.