After an incredible hype cycle back in 2005 many organizations took the plunge. We were going to ride SOA into a new highly productive development environment. The idea was we’d build business services and then start composing applications on the fly based on these service components. The reasons for diving headfirst into SOA included:

• Gartner and many tech magazines pushed hard that this was the wave of the future. We haven’t had a tech hype cycle since.
• At a high level the story was compelling, especially the idea of working closely with the business.
• Enterprise vendors needed a new story to sell complex, high cost software after ERP packages started having so many expensive failures, and app servers were largely commoditized by the success of JBoss.
• As a baseline XML had become well understood, and web services were a much easier integration story than CORBA.

So a large number of IT shops jumped in to build their SOA solutions. Some efforts crashed and burned completely and the organization walked away. Others fought through the learning curve, the mass of WS* specs, and delivered some useful services. Still others worked with large system integrators and delivered solutions that were little more than overly complex integration services with large XML payloads presented as a grand new SOA Architecture.

Many others sat out the the whole SOA revolution. They didn’t go out and buy an expensive ESB/BPEL/Composite Application Suite. They let others go through the pain and tried to decide if it was worth it. In the Java space it was similar to the large number of shops who decided to pass on EJB and just stuck with web containers like Tomcat.

What I see now out in the field is a number of those IT shops taking a second look at SOA. There are a number of factors that make it worth taking a second look at SOA:

• Integrating with other organizations these days often assumes you can hook up to a web service they already have.
• The testing story has gotten better, even if much of it is still functional testing.
• The tool vendors have created reasonably decent tools unlike the early generation that were plagued with bugs
• The open source solutions things like Camel and ActiveMQ are proven
• The cloud computing meme is putting an emphasis on thinking and utilizing services to create a complete application.

As I’m out at client sites over the next year I expect to continue to see this trend increase with many sites taking a second look at implementing some sort of SOA. (And yes SOA is still a fuzzy term that I don’t hope to define here.)

I’ve been meaning to put together an example of all the Hamcrest assertions that have been added to JUnit 4 way back in 2007 now. My assumption based on a number of recent client engagements is that if unit testing is being done with JUnit the default is still to rely on assertEquals() as the default. I found developers were very enthused about the new assertThat() style if you showed them some examples. In order to better understand all of the new Core Matcher options I put together a little tutorial example of all the defined matchers.

• JUnit 4 Hamcrest Assertions with Complete Examples

Everyone has that trunk of old junk tucked away in the attic. It’s almost spring and time to think about getting organized, tossing out old junk, and having a garage sale. Apache has managed to create an online concept of a software attic. Old open source projects that have outlived there useful lives can be retired there. The concept is intuitive and useful in a world with hundreds of thousands of open source projects, many abandoned early in there life.

I’m not sure how long the Apache attic has been around, but I came across it accidentally. I’ve been doing a lot of architecture assignments recently which often involves digging through big source code trees to get a sense of how their development has evolved. In Java land I run into dozens of different web frameworks, and I came across a project utilizing Apache Beehive. I recalled it was some extra XDoclet like commented annotations on top of Struts that was adopted by Weblogic as their default framework years ago. I’m all too familiar with classic Struts, but now I needed to go look up Apache Beehive to see where the framework was currently.

It didn’t take too long to arrive at the Apache Attic page. The mission was stated as such:

The Apache Attic was created in November 2008 to provide process and solutions to make it clear when an Apache project has reached its end of life.

Brilliant! Explaining that the time has come to evolve the codebase is much easier when Apache has officially retired the project. Unlike so many other open source projects I don’t have to do the following investigation on arriving at some SourceForge page where it appears the project has been abandoned. I don’t have to make an argument that though despite a few check ins in the last year that on active projects there will typically be hundreds of check ins and that the project is essentially dead. I don’t have to point out that despite having a plugin architecture for some framework there are only say 5 plugins that have been developed and the last one was 3 years ago. And finally my explanation to management has the official endorsement of Apache.

I’d like to encourage more of this in the future. I await the day when Struts Classic moves to the Apache attic.

The image above probably needs a bit of explanation. After having a lingering todo I finally made a donation and requested a Green Clean Code band from Uncle Bob Martin. I was at a talk of his at SD West 2005. At that point he pointed out a rubber band he was wearing that he would snap on his wrist every once in a while to remind him to run the tests. It was a mark that he took TDD as part of his professional duties.

The green band you get sits at the top of the image. The yellow band below wasn’t a warning type band. The words on have worn out, but it said ‘Go Kenji!!’. Kenji is the son of a neighborhood friend who was diagnosed about a year and a half ago with Stage IV Neuroblastoma. It was heartbreaking to see him go through chemo radiation and finally a stem cell transplant, but he’s a happy cancer survivor today. Today was a good day to retire the band. Cancer is a nasty disease, but it’s better to move on as soon as you’ve vanquished it.

So next time I run into anyone I’ll be wearing this band as a reminder to always keep my code clean with tests and refactoring, even when that code is hairy or written in some language and frameworks that are inherently hard to test.

Michael Feathers wrote a tough post recently on UI testing tools.

The fact of the matter is that UI based testing should be used for UIs: that’s it. You should not be testing your full application end-to-end through a UI Testing tool. First of all, that sort of testing couples some of the most important tests in your system to one of the most volatile parts of it.

—Michael Feathers

I understand the frustration he speaks from, but I’ve always realized that you don’t really want to completely try to test through the front-end of the application. It can be useful with legacy systems to get a minimal test harness in place. With the right testers I’ve even seen some of the Mercury products used effectively for UI testing, though it probably required a 3-1 ratio of QA to developers and the tests were not customer tests, but written more as a regression suite.

My use of functional testing tools like Selenium has generally been for a spattering of end to end tests and some amount of customer tests. I’ve never really tried to achieve a high level of coverage with these tests. Obviously testing the business logic through something like Fitnesse is more effective or even setting up BDD style tests tend to make better customer tests.

I’ve actually been saddened over the past five years or so to see that tools like Fitnesse haven’t seen more adoption. I think the BDD development has put more of a focus on developing customer style tests, but in general if there are automated end-to-end test suites in place there often overly reliant on something like Selenium.