Big Bad Architectural Smells - #4 Feature X cannot be unit tested

I've heard this twice now in the last two weeks - "Feature X cannot be unit tested" or "Feature Y is not meant to be unit tested" - so to test it or test with it, you have to deploy the whole application in the container. Unfortunately my stuff completely relies on X as a major integration point and I want to unit test my stuff sitting on top of this.
(True I guess I'm writing more of an integration test than a unit test but still . . . .)

Frankly the situation is unacceptable and the developer should be embarrassed. Pretty much everything can be unit tested - it may take a lot of work in some circumstances, but it's doable. True for me, I could write a mock object but that's so much bloody extra work :-)

In the end I figured out a pretty easy way to Unit test both features (and, surprise, surprise, it wasn't that hard). What was *not* surprising for me was that the lack of unit testing in those features was somehow strangely correlated with a significant number of bugs also in those features - funny that! ;-)
Bugs that would have been found with - you guessed it - some simple unit tests!

Being unable to test a feature is a "bad smell" - things like testing database driven apps are hard, yes, but far from impossible and any time invested in helping developers unit test (e.g. mock objects or test database load / unload scripts) is very well worth it IMO.

For those looking beyond just plain old JUnit - I strongly recommend folks take a good look at extensions such as

• HttpUnit for unit testing web interfaces
• DbUnit for a ton of great services to help test database driven apps
• Cactus for container testing
• MockEJB for Mocking EJBs (kind of obvious eh?)
• EasyMock for plain old Mock objects

for nice integration with Eclipse I recommend EclEmma to give you code coverage reports to go with your unit tests (it is surprisingly well featured despite being only at version 0.1.8 at the moment) .