Writing tired, formulaic Top-10 lists or posts with provocative titles is a shameless way to attract traffic. And I want in on the action! So without further ado, here is my Top Ten Eye-Catching DZone Titles.

1. 10 Ways to get an article on dzone - I’m being self-referential. That means I’m clever!
2. I’m Going To Scale My Foot Up Your Ass - (Not suitable to read at work, I’m afraid.)
3. Ohh regex you naughty naughty boy you - …so very very naughty…
4. Dethreading a Chicken - Sounds complicated.
5. Are You User Experienced? - I voted this one up just for the title.
6. Boo! I’m an Event Manager
7. Revenge of Hello Terracotta - Aha! Someone wrote a post which was a sequel to another post, and in naming it cleverly referenced old monster movie sequels like Revenge of the Creature or Revenge of the Son of Blacula’s Return. What a funny guy that author must be!
8. Hell Hath No Fury Like Polymorphism Scorned
9. You’re Fat and I Hate You - No idea what the post is about, love the title.
10. Unit testing is dumb - I am shocked, shocked and appalled, at such an obviously inflammatory title! What troglodyte wrote this crap?

Thanks for reading…suckers!

My previous post was about whether Guice should be used in unit testing, and Crazy Bob himself commented:

I prefer the simpler unit test. I think the real moral of this story is that unit tests alone are never enough.
Also, you did get the error right away when you started your app. That’s like an automatic test that you needn’t replicate manually (comparable to a compiler check).

I started to reply and my comment quickly grew long enough that I decided to just write another post. So, should Guice be used in unit tests? I hate to be wishy washy but I think the answer is it depends. As happens so often in software development, there are conflicting forces at work. In this case I think two conflicting forces are ease of unit testing versus fast feedback loop.

One thing I do completely agree with Bob on is that unit tests alone are never enough. Alex Miller wrote a great post about that called Weaving the Test Fabric.

Fast feedback loop

Different parts of the test fabric perform differently and are intended to be run at different frequencies. It’s common to only run all of the automated tests once during a nightly build, especially if any of the system tests are long-running and/or resource-intensive enough. It’s common to have a medium-weight suite of tests which a developer is expected to run once prior to committing the code, but which may still take quite a few minutes to run. And I prefer to have a suite of as many automated tests as possible which run fast. If you have a fast running suite of automated tests, then you have a fast feedback loop. I’m talking under twenty seconds, the sort of suite you can run in between every single change, as you work. Such tests most likely make heavy use of mocks and have no dependencies on external resources like db’s, file systems or network connections. Such tests are most likely unit tests.

With Guice, as with any code, the question is: how long can you stand to wait to find out if you implemented, or broke, something?

I would not be able to stand having to start the whole application up every time I was debugging my Guice usage. Bob Lee reminded me that you can still have automated tests that test your usage of Guice, they could be component or system level automated tests, not necessarily unit tests. They could even be included in the fast running suite.

Ease of unit testing

It is so important to keep unit tests, and unit testing, simple. For the sake of all current and future developers working on the code, the barriers to unit testing need to be as few as possible - basically just know JUnit. It’s hard enough as it is to get people to write unit tests. So, having thought about it, now I’m not so sure it’s worth having Guice in unit tests if it burdens my peers. I know how overwhelmed I feel when I work on a project and find I have to learn additional in-house unit test conventions and special TestCase subclasses that I’m expected to start with. It’s an awfully attractive idea to keep unit testing confined to simple JUnit tests, and leave fancier stuff for more complicated integration-style tests.

This is all predicated on the idea that Guice is not mainstream yet, as JUnit is, and would still be a burden to have to learn just to unit test with. If Guice ever becomes more widely used and understood, then I might revert back to my earlier conclusion. After all, Guice is the new new - why not embrace it in unit test code if it is being embraced in production? I like the API very much and think it could easily become part of the unit testing vernacular.

Conclusion

The two forces I mentioned above do not have to be diametrically opposed. Thinking about it now, I could envision component-level or subsystem-level automated tests that do nothing except test the Guice dependency injection for that component. Such a test could still be fast-running if mocks are used as appropriate - Guice itself is performant enough thanks to it’s pure Java implementation. And such tests would naturally force the developer to place the proper Guice annotations in the proper place. Unit tests could remain simple JUnit tests.

Last week was shortened by jury duty on Monday. Fortunately, I was never selected from the pool, and on Tuesday I was back to work.

There are (still) a number of monkey failures (such as this one) that I need to get working on.

However, I discovered I could procrastinate tackling those by checking the forums. I decided to try to answer this post (which has since been addressed by a couple of my teammates). Almost two days later, I conceded that it’s really really hard to try to cluster the underlying javax.swing.text.AbstractDocument of a JTextField. I still haven’t got it. (See gkeim’s response for a clever workaround.)

I finished up the week by working on droid. One of my peers was having trouble running a test in which he wanted one of the spawned workers to have a different tc-config than all the others. There are some weird subtleties in passing vm arguments through the agent which are intended for the worker, but as it turned out, I believe the functionality is already there and didn’t require any changes on my part, just an explanation of how to do it.

At my Guice presentation recently, I used some small code exercises to demonstrate the basics of Guice. Here is my simplest example, involving a Service, a Client needing a Service injected, a test case, and an Application.

First, the Service:

Next, the Client, and it’s test (JUnit 4):

And finally, an Application that ties it all together using Guice:

During the talk, Jeff Grigg had a question followed by an interesting comment. For his question, he asked me to remove the @Inject attribute from Client and re-run the test. I did, thinking I was about to demonstrate a typical helpful Guice Exception. But the test passed. I was momentarily lost, until I remembered that the unit test did not use Guice at all. I ran the Application just as a sanity check, and it was indeed broken.

Jeff was on it like a hobo on a ham sandwich - I had broken the application but the test still passed. My test did not justify the use of the @Inject attribute.

He was absolutely right. I realize now that I had been following the example from the Guice Developer Day Slides, which had taken a non-Guice example and migrated it to Guice, leaving the JUnit test unmodified so that, like my test above, it continued to manually pass a mock to the client code and did not use Guice. This, I realize now, is fine for a tutorial but it not truly Test Driven Development, where every line of code has some test to justify it’s existence.

Naturally, Jeff raised the question - should Guice then be used in unit tests?

I think the answer is yes, why not? After all, Guice suggests it be thought of as the new new, and that using Guice is no more work than plain old factories.

If Guice were used in unit tests, then the tests would naturally require that the code have the necessary @Inject attributes, or whatever other attributes are necessary for Guice. The only difference would be that different Modules would have to be created for the tests, which contained bindings which differed slightly from the production Module(s).

I tried implementing a new client, strictly adhering to TDD and using Guice in my unit tests. Here is what I came up with.

There are two things I notice. One is that my mission is accomplished - my Client’s @Inject attribute is now truly unit tested - the test will fail without it. As a bonus, Client is slightly simplified in that it no longer needs a constructor which accepts a Service. The other thing I notice is that the test is somewhat more complicated, but really it’s only the addition of a Module and Injector.

My feeling is that it’s worth the extra effort to use Guice in unit tests, if you’re going to embrace Guice in your production code anyway.

In a future post, I’d like to investigate whether there is a better way to integrate Guice with JUnit, alleviating the need to write boilerplate unit testing Modules over and over again. Just tonight I noticed both GuiceBerry and AtUnit which potentially address this and look somewhat promising.

I gave my Guice presentation tonight. The best part of the talk for me is that a lot of people chimed in with comments and questions, which is just the way I like it. Thanks to everyone for attending and for generating some good discussion. My talk was comprised mostly of code samples, the presentation materials will soon be available on the JUG knowledge base.

It was great to see some old compadres (Greg, Rasesh, Jeff C and Dennis) as well as introduce myself to some familiar faces in the St. Louis Java community (Michael, Mark, Jeff G, Weiqi, Kyle).

The differences between Guice and Spring were definitely a frequent line of questions and comments. Some open questions and comments that came up related to this are:

• Is it ever preferable to have your application’s configuration truly outside of the source code (a la Spring xml)? Is there value in reconfiguring the app without rebuilding, or is that just a pipe dream? Is external configuration desirable so that non-developers can reconfigure a system, or is that fraught with peril?
• What would be a reason to integrate Guice into an existing code base which uses Spring, especially if you are already leveraging Spring 2.5’s annotation-based dependency injection? I conceded there may be no reason. Kyle Cordes pointed out that in a pristine, pie-in-the-sky world this may be true, but so often in the real world there are large clunky heterogeneous revenue-generating apps and components which need integrating, and you may be in a situation where you have no choice but to integrate Guice with Spring. In that department, Guice scores points for having integration with Spring built in.
• Is there a Guice parallel to Spring’s named instances? That is, in Spring you can configure beans which are named multiple instances of a single concrete type, and said beans can be injected. Jeff C suggested that a Guice Provider might supply that behavior. Kyle pointed out that, by Guice’s very nature you may not need to declaratively configure named instances because Guice entirely operates as Java, and you should be able to just programmatically get or create whatever instances you want. It’s definitely a different mindset than Spring.

Weiqi urged some of us to read the Guice source code, particularly to be impressed by some clever use of generics. I plan to read a little of it right now.

This just in - Weiqi has already written a writeup of my talk on his own blog. Thanks Weiqi, I’m flattered!

This Thursday night I’m giving a presentation on Guice at the St. Louis Java Users Group. Come on out and see!

My talk is shaping up to be mostly code and very few slides. In the first half I will be demonstrating the basics of Guice, what it is and what it can do, via the usual simple contrived code samples that you would expect. In the second half I hope to address how you might introduce Guice to an existing codebase. Specifically, I want to look at Guice’s integration with Spring, and also look at some basic strategies for refactoring out smelly code like Singletons or tightly coupled spaghetti code.

Boy, I hope it turns out as good as the above paragraph suggests!

If you’ve never been to the JUG before I encourage you to come check it out. It’s very informal and relaxed, it’s a great place to network and plug in to the St. Louis Java community. Plus there’s food and refreshments, and almost always cool swag being given away.

One last thing - I would be remiss if I didn’t mention that my company, Terracotta, has support for clustering both Spring and Guice at the JVM level. (There - now I can expense this blog.)