Bill the Plumber

There were some interesting side conversations going on in the comments of my Java EE wins over Spring blog.  In particular, a few people were arguing over the value of Mocks.  I always considered Mocks a bogus pattern.  Only time I ever use them is when I’m initially starting a project and I don’t have full implementations of a particular subsystem and I need to test that something works.  You see to me, your GIT master branch, or your SVN trunk is a sacred place.  I fully believe in the idea of continuous integration.  But to have a pure Trunk, you have to test your code, as close as possible, to the target environment it is supposed to run in.  Mocks go counter to this idea.  And give you false sense of security.

My colleague, Stan Silvert said it best:

When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.

What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.

The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.

I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.

Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.

Personally, I’m a very paranoid person when it comes to development.  Earlier in my career I did a lot of demos and live coding in front of an audience.  When you’re in this type of environment you live by the mantra that anything that can go wrong will.  So, when rehearsing, you always mimic as much as possible what your setup will be.  I carried this paranoia to Iona (an Irish company), when I worked on Orbix there.  We had a rule, that if even one test (integration or whatever) failed, you were awarded the Guiness Penalty.  If you broke the build, you had to buy every one on the team a pint of Guiness.  IN this environment, Mocks are a waste of time, both in build CPU and in coding time as you still had to run integration testing before you committed anything (unless of course you just wanted an excuse to have a few beers).

So unless a particular integration test is ungodly slow, don’t use mocks.  Stan again, said it best:

…the days of the 2 hour in-container smoke test are over.

Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.

But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.

With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore.

I just read an interesting blog by Savio questioning the value of LGPL.  IMO, he has something right, the OSS license chosen for a project is not that important as far as adoption or business goes.  The most important driver for OSS is and always has been the brand of the project.  Like their commercial counterparts, how the project is perceived by consumers is what drives both adoption and business.  So, I agree, LGPL doesn’t add a lot of value.  But, it goes both ways, the Apache license is also not that important either.

If you boil it down, the distinctions betwen GPL, LGPL, and ASL are pretty much meanlingless to most consumers of OSS.  How so?

1. The viral nature of GNU bases licenses is only triggered when binaries are distributed.  Most consumers of open source do not distribute software publicly.

2. LGPL is also not an issue for ISVs as long as they leave the binary as-is.  Its viral nature is triggered when the project is both modified and distributed.

So, when you take these two points together, the number of people affected by the differences between GPL, LGPL, and ASL become fewer and fewer.  GPL does not affect > 90% of OSS consumers.  For LGPL, the number of people actually affected by the license becomes a number that you can probably count on one hand.  The ones affected are the ones who actually want to use derivatives of the project within their own competing initiatives that are not LGPL-based.   So, do you see how meaningless it truly is?

Why making these distinctions is damanging

This all brings me to my final point.  The whole push by Apache.org and its minions that ASL is the one true license is just damaging to open source.  When you consider the handful of individuals affected, you got to question the motivation for it, especially when you match it up to LGPL.  The thing is though, highlighting the differences only helps those handful of people that have selfish motives and/or want to exploit OSS for commercial gain.  Believe me I’ve lived this.

Back in 2003, a group of JBoss contributors tried to fork both the JBoss code base and the JBoss business.  IMO, their motives were mostly financial.  They wanted a bigger piece of the pie that Marc Fleury was unwilling to give up.  Whether or not they were right to do this is besides the point, there are good arguments on both sides, and whats done is done.  They initially derived themselves from the JBoss codebase, went to Apache, and thus Geronimo was born.  We complained that their derivation was both a copyright and LGPL violation.  In the end, they started over from scratch (don’t think the LGPL had value for JBossians back then?  think again!).  When Geronimo 1.0 came out, their feature set was vastly inferior to JBoss so their push was that it was the only Java EE implementation that was ASL.  That LGPL was scary and the only way to get over the fear was to use ASL-based projects.  IBM got into the act when they purchased Gluecode (and all the Geronimo developers) and embraced Geronimo as their children’s edition of Websphere.  Again, the main push was that Geronimo was ASL based.

We then come full circle to 2010 with history repeating itself (well, sort of).  You have Tom Bayerns leaving Red hat for Alfresco to create a competing BPM engine.  Now, I consider Tom a friend, and I completely understand his reasons for leaving Red Hat.  That being said, launching a new open source BPM engine with the premise being “we want to create something in ASL because it is better for our business”, is not the way to go about it.  Again, it smacks all over of having nothing but the zero-add of the ASL distinction.  And, is just completely irresponsible.

If you are an Apache guy, you should be appalled by behavior like this when it happens.  Individuals and companies that use ASL as a weapon to further their own selfish and commercial needs should be castigated and called out instead of championed as the reason why ASL is so cool and LGPL is so bad.  Respect the choice of other open source developers, propagating the myth that an ASL project is superior to a LGPL project because of license distinctions does nothing but hurt the open source movement as a whole.  We need to stop eating our own.

Finally, I just don’t want to bash on Apache and ASL.  Joining the GPL revolution isn’t so hot either.  The fear of GPL virality is used extensively in the dual-licensing ploy of commercial interests.  Think MySQL.  For me, I would never pick GPL, because I believe in the freedom of letting ISVs distribute my stuff as-is.  As for LGPL vs. ASL?  I could care less, it really doesn’t matter.  You don’t see JBoss caring so much either.  Drools is still ASL as well as a number of other jboss.org projects.

Anyways, have fun with this, and remember taking any one position to seriously is unhealthy.