JUnits that reach the sky!

We have a service oriented architecture.  We have multiple JVMs that each act as a service.  Every connection between two JVMs is protected by a unique user id/password.  I got a request to allow a new id to connect to one of my JVMs.  This by itself wasn't normal.  What wasn't normal was the format of the user id.  App applications follow a given format to identify the purpose of the user id.  This id didn't use that format.  I inquired about what the id was for, and I was told that it was for JUnits.  This confused me.  I decided to go farther down the rabbit hole.

There is a webapp that doesn't have any JUnits.  We have had issues in the passed where a fix for one issue caused another issue.  Someone decided to write some JUnits for the webapp to prevent these type of issues from occurring.  This seemed like a good idea.  This person didn't want to write only unit tests, though.  He wanted to write full integration tests.  He wanted to write a test that connected to the DEV instance my JVM to make sure the webapp worked with the real service.

Adding a new user wasn't a big deal.  I expressed concern over the testing strategy that was going to be implemented.  The people I was talking to were confused.  They didn't understand why I had issues with the strategy.  I finally expressed the fact that if my JVM is down, then their builds would fail.

Builds are supposed to be a repeatable process.  It something happens to the output of your build, you should be able to re-create the output by re-running your build.  This is why your build should not depend on any external services (that are not related to your build process).  I have seen far too many "unit" tests that connect to databases.  Tools like EasyMock exist for a reason.  There is also the art of writing "testable" code.

In the end, they opted to forgo connecting to my JVM as part of their build process.  I think it was a wise decision.