Unit Testing Service Component Architectures

Nice to see someone at IBM has finally taken a look at how you might test their wonderful SCA modules.

Turns out you have to go through many steps in Websphere Integration Developer (WID) and it appears to rely on Cactus which tends to be a real pain. Getting the whole thing setup involves several XML configuration files and plenty of clickety-click development. And they aren’t really coming from the perspective of test first, since you always lay out the process first using their visual modeler. I personally despise this whole style of development, but being able to actually force it into something of a test harness does make it a bit more palatable.

Getting to a green bar with an SCA module:

  • 47 steps.

    1. To import these modules into your workspace using WebSphere Integration Developer, select File => Import.
    1. In the Import dialogue, select Project Interchange, and then Next.
    1. Select the Arguments pane. Under VM arguments enter the following code(Figure 12):

    Note that this specifies the localhost and port 9080; if your server or port for HTTP requests are different, you will need to adjust this string to match your choices.</li>

      1. Select Run to initiate the test.</ul>

    Getting to a green bar testing a POJO:

    • 4 steps.
      1. Write a failing test.
      2. Implement a class and method to fix compiler errors.
      3. Implement just enough code to pass the test.
      4. Run the test for a green bar.

Everyone Writing Tasks

I changed up the usual way I run the detailed part of our Sprint planning meeting with everyone coming up with tasks. For almost all prior meetings:

  • Stick selected backlog items for the Sprint up on the wall on giant stickies.
  • One by one lead the discussion on what tasks need to be done for each item.
  • Write each task down, come up with an hour estimate, and generally let someone claim the work or assign it to the team.
  • Repeat until finished with all backlog items.

Today at the suggestion of some of my developers on another project, I changed things up a bit:

  • Hand out large 5×7 stickies and pens to everyone on the team.
  • Stick the backlog items on the wall.
  • People started to write down their tasks and walked up to the wall and pasted them under the backlog items.
  • Then I just facilitated walking through each backlog item and asking if we needed any more tasks and adding hour estimates to tasks that didn’t have them. In some cases team members just wrote down new tasks as they thought them up and added them throughout the discussion.
  • Repeat until finished with all backlog items.

Overall the experience was better, we got done a little quicker, and the tasks had the names the people doing the work had defined.

My hesitation to try this approach had come from one early Sprint on a project. I had handed out stickies to start the process, but almost everyone was new to Agile and they hardly wrote any tasks. In order to really pull out the tasks I had to stand up and really lead the discussion, writing down each of the tasks myself. As I got adjusted to working this way I just fell into a habit.

It never hurts to reexamine and test your assumptions.

Using this Keyword to Call Private Methods

After a recent code review I noticed a lot of code similar to the following:



if (this.isValidProfile()) {

Our coding standards allow for using this with fields to make the distinction clear:

private int count;
pubic void setCount(int count) {
  this.count = count

We adopted The Elements of Java Style for our coding style guide about 2.5 years ago, but this is a case I’d never spent much time thinking about. I find it a lot clearer to write something like:



if (isValidProfile()) {

I always assumed this was a well understood convention, but after spending some Googling around I found nothing specifically on idioms with using this with methods.

I think the best evidence in favor of not using the this keyword is with Martin Fowler’s Extract Method pattern. You often create small methods by doing a simple extract of a code fragment on a method that’s getting a little long. And Martin’s example suggests calling the extracted methods with:




For me it all comes down to better readability, but we’ll probably have a short meeting with some of the senior developers to toss it around and come to a final decision. If we hadn’t been doing code reviews on a regular basis we might have never addressed this issue.

Setting Up Acceptance Tests

I’ve been intrigued with Fit/Fitnesse since Bob Martin introduced me to it at a session at SD West 2005. Of course that was about 18 months ago and despite playing with it a fair bit myself and even giving a talk on it at our local JUG, we still haven’t implemented it on any projects. Given that I’m unfortunately the resident expert on it, I think it’s finally time to push it directly even if that means doing some coding to show people how it could work on a real project. Now I just need to find time to keep up with the management duties as well.

Haskell On My Radar

I’ve latched on to the Pragmatic’s suggestion to pick up a new language each year. This year it was Ruby of course. A couple things from Smalltalk to Lisp to Haskell have been buzzing around in my head, but I think I’ve settled on Haskell as the candidate. The main reason is being a functional language it has the ability to stretch my skills the most.