As one trying to implement TDD or at least rigorous unit testing in a real world web development shop I am constantly confronted with the issue of how to unit test our Struts applications.

I’ve built a fair number of Struts applications myself over the past few years. I started down the Struts MVC path because I don’t like reinventing my own frameworks and it was 2002, the first Struts books were appearing and it was already becoming the default way to write new Java applications. It certainly felt a whole lot better than banging out a JSP front end hooked to servlets that did raw JDBC to the database.

I remember diving through the Programming Jakarta Struts book from O’Reilly, trying to understand the theoretical underpinnings and just best how to implement the framework. I remember reading in the books relatively simple examples how one should create their own model layer and that Struts didn’t really provide one. My compatriots at the professional services firm I worked for at the time nicknamed me ‘The Professor’ for my academic need to understand the theory behind these frameworks. I thought the basic idea was wonderful, but when the rubber met the road as usual we ran into issues. Eventually the design evolved into your now traditional Struts app with Actions, FormBeans, Value Objects like Person, and Services which were really thin DAOs. It met the requirements for the client which is the final evaluation for any project so despite a lack of any real unit tests beyond the Service layer that were dependent on the database it really didn’t have much in the way of unit tests.

So your options when you start to really examine them are something like:

• StrutsTestCase
• HttpUnit or derivatives like JWebUnit
• Cactus
• Give up and just test the business logic

I’ve gone through all of these and they lead me to a similar conclusion.

StrutsTestCase is a pretty reasonable mock framework for testing Struts applications and faking the Response, Request, ActionMapping, and ActionForm objects for every execute method. That said I’ve had a lot of issues just getting it setup in many cases, but that may be from unfamiliarity. Anyway it does a fairly decent job of letting you setup and test Struts actions where many times the business logic is embedded.

HttpUnit or more friendly derivatives like JWebUnit allow you to test the ever so hard to test JSPs that are generally put together with Tiles in a Struts project meaning they’re hard to test any other way. While this can be very valuable testing it really isn’t unit testing, it’s functional testing or acceptance testing and it’s dependent on the container being up and running to do the tests. On top of that the feedback loop is longer because HTTP even to and from a localhost instance just takes some time. In the end they can be very valuable tests, but they’re really something you want your automated build tool like CruiseControl to run with every build, not something you’re going to run a lot in the midst of coding.

Cactus allows you to run the tests inside the container by literally firing it up. I’ve had a few experiences getting Cactus actually running in the container and my general rule has been its not worth the effort. You can of course run StrutsTestCase this way as well, but I much prefer the MockStrutsTestCase approach since with unit testing I’m trying to take out my dependencies and test small sections of code, typically individual methods. Again it’s just not that satisfying to use Cactus to setup tests and the feedback cycle is quite a bit slower.

Then you can always give up and just unit test the business logic. It sounds good, but then it generally turns out a lot of the business logic is in the Actions and really the only other logic is in the DAOs. So you can unit test the DAOs, but then your dependent on the database again even if your using something like DbUnit for setting up and tearing down records for the tests.

OK, so there’s solutions for all of these you’re saying if you’re a relatively sophisticated java developer. I think that’s right. Really there should be almost no business logic in your actions at all, that should all be handled by a service or business delegate. These are just POJOs so you’re able to use JUnit to your hearts content to do real unit tests. You can pull out the database dependencies by implementing Factories to produce the DAO objects and then passing back a mock DAO implementation for testing maybe based on some system property. Then you can use StrutsTestCase to check that a ActionForm’s validate method works or an Actions execute method works. Then to complete things you write some JWebUnit tests for end to end front end tests and a suite of tests using the real DAOs so you can make sure you get the right stuff out of the database. The last two you only run with the automated build since they take longer. The other tests are true unit tests without significant dependencies so you should be able to run the whole suite in a few seconds for most projects.

Great, until the real world shows up. The truth is the vast majority of Struts apps I’ve seen write most of the business logic into the Actions. Many of the books out there pretty much show this as the way to do things from their examples, even though they mention the more sophisticated approach. To make things worse the DAOs are almost always instantiated and used in the Action’s execute method. Then top this off with the fact that a significant number of Struts projects then leave a lot of java code even in the JSPs instead of relying on JSTL or the struts tag libraries.

In my particular situation I’m mentoring up a fairly large group of developers who come from a ColdFusion, Delphi, or mainframe background so once they learn the basic Struts MVC paradigm they’re off and running. I’m still working on ways to instill unit testing, but I’m stretched thin and in an Agile world where you can’t do everything and the applications aren’t that large instilling the value of unit testing isn’t that easy especially if it involves designing their applications to be testable instead of relying on deploying the app into something like Tomcat and then manually checking the pages every few minutes. And when they go out to Google to figure something out the examples rarely mention why putting all the business logic in the Actions is probably a bad thing. After a first round of first time Struts projects I have some ideas of how I’m going to try to instill TDD even in the Struts world.

It’s a pretty simple formula:

• Run training sessions on basic JUnit functionality and how to write a test before code and the benefits.
• Trying to assign my relatively few experienced J2EE developers to each new project
• Running more specific training sessions on JWebUnit, StrutsTestCase, and how to use factories and a POJO service layer to separate the Actions from the DAOs.
• Move all of our projects into running CruiseControl with a target that invokes JCoverage or Clover and fails if we don’t achieve at least 50% test coverage of the codebase. I’m pretty sure I’ll have to adjust things here, since some code like JavaBeans are hardly worth testing.
• Evaluate and adjust

I’m just hoping that 6 months from now that we’re starting to roll out our first TDD projects, have to see how it goes.

I’ve spent the last couple days in between meetings and fighting fires trying to review two Struts projects my teams are working on. I keep trying to add tests only to find that it’s much harder to add any sort of meaningful test than it should be. These are not big applications and they’re being done by developers on learning curves who aren’t too OO familiar so the bulk of the code and logic is in JSPs or Struts Actions. Unfortunately that means they’re immediatly hard to test. So far these are the things I keep running into:

• The easiest tests are functional end-to-end tests using something like JWebUnit, but brittle and they take too long to run to do more than a few.
• StutsTestCase just doesn’t provide to much besides firing off an action from the mapping file and seeing if it creates the expected results. Generally it just feels to trivial.
• JSPs are just a pain to parse and have to be rendered anyway especially since tiles and the like are in use. And generally what does parsing a JSP really tell you. You end up in the GuruTestsCode pattern real fast.
• You can write tests around the DAO layer, but generally you’re just testing against the live database, again too slow.
• There are always some validation Utility classes, that at least are easily testable

I’m going to circle the wagons tomorrow and bang some ideas off my top developers, but I’m beginning to think without rethinking the design for testability that unit tests don’t work to well in this environment.

Managing techies, geeks, rocket scientists, and software engineers is hard work and more of an art than a science. Still given the current techie focus on <a href=http://www.awprofessional.com/series/series.asp?st=44117>patterns</a> or more importantly <a href=http://c2.com/cgi/wiki?AntiPatternsCatalog>anti-patterns</a> I’m prepared to share my delicately researched opinions on the anti-patterns of technical management. And I’m willing to ignore that fact that the bulk of my management experience is with techies and not other segments of society or the fact that I went to a die hard engineering school where I was informed more than once, “It’s not a UNIVERSITY, it’s an Institute of Technology.” My experience is universal darn it.

Over the next few months I plan to examine the many anti-patterns of technical management, many of which I’ve been guilty of invoking. I’ll look at anti-patterns from “Coding Manager” to “Business Requirements are for Business Analysts”.

For those of you who’ve been following my personal cancer battle, I’ve labeled myself a survivor again as I’m completely cured at this point. Thus I’m back to ranting about techie topics instead of how oncology doctors have trouble dealing in percentages when explaining your long term survival rates.

How not to lead techies

Managing techies, geeks, rocket scientists, and software engineers is hard work and more of an art than a science. Still given the current techie focus on patterns or more importantly anti-patterns I’m prepared to share my delicately researched opinions on the anti-patterns of technical management. And I’m willing to ignore that fact that the bulk of my management experience is with techies and not other segments of society or the fact that I went to a die hard engineering school where I was informed more than once, “It’s not a UNIVERSITY, it’s an Institute of Technology.” My experience is universal darn it.

Over the next few months I plan to examine the many anti-patterns of technical management, many of which I’ve been guilty of invoking. I’ll look at anti-patterns from “Coding Manager” to “Business Requirements are for Business Analysts”.

For those of you who’ve been following my personal cancer battle, I’ve labeled myself a survivor again as I’m completely cured at this point. Thus I’m back to ranting about techie topics instead of how oncology doctors have trouble dealing in percentages when explaining your long term survival rates.

Made it to 35

After the last few months I was really happy to see my birthday. Micki and Kassie even did a surprise birthday party, and in an amazing show of patience Kassie didn’t leak a word. So life is very good.

Not much to report on the cancer front. Looks like I’ll be doing a little local radiation. Things have advanced so they can do ‘intensity modulated radiation,’ without much extra risk. So 20 days of treatment to go and I’m all done. They’re quick and easy though compared to anything else.