I frequently encounter two problems with JUnit’s tearDown:
1. tearDown is not executed if setUp fails, leading to resource leaks.
2. Mock verification calls in tearDown can obfuscate original causes of test failures.

Many developers work around the mock verification problem by commenting out the verification to expose the original problem. The problem with this is that it’s very easy to forget to uncomment the verification calls, hiding future test failures. Another alternative is to blatently violate the DRY principle.

My solution to these problems is to introduce a custom TestCase that overrides runBare, the skeleton directing the steps performed in a test:

public void runBare() throws Throwable {
    try {
        setup();
        runTest();
        tearDownExpectations();
    } finally {
        tearDown();
    }
}

tearDown can now do its thing if setUp fails and tearDownExpectations (a Template Method containing Mock object expectation verification calls) will only be performed if the test method is successful.

I’ve recently been pondering why university numbers in IT related courses, at least in Australia, have been dwindling.

On the surface the industry is promising, plenty of prospects and above average wages sends a message of a healthy market.

But, in my opinion, under the surface the water is fairly murky.

Job satisfaction is always at risk. Projects are more likely to be canned in IT than any other industry. It’s a strange feeling to have your creation (or at least something you’ve helped create) discarded, never to see the light of day. Looking at it deeply, it can easily effect your notion of self-worth.
IT has little room for attachment to one’s work. Your work can and does change to the point where it is unrecognizable at the whim of another. The artifacts of good projects are usually recognized as works of a team and not individuals. All this mounts up to, in the first few years of your career, learning to become detached from your work. I see it as about accepting that emotion takes a back seat to evolution, and the individual takes a back seat to the team collective.

Individualism does, of course, has a place. Some people are more influential than others and every workplace has personalities.

But the water is clouded most by the growing trend of offshore development. IT has been - and continues to - follow the trend of goods manufacturers, moving production to countries with staggering cheap labor. Simply put, developers in other countries are dated or their salaries are bound to fall. How long it takes before offshore hits critical mass and becomes the norm (like in manufacture) is anyone’s guess, but I certainly am not hedging my bets on a long term career in IT.

When I consider the thoughts of my father early on in his career as a refrigeration mechanic, an industry he has served for 50 odd years, to mine now where I see gray clouds forming around IT in first world countries – our thoughts must be miles apart.

That said, I continue to enjoy my profession – most significantly as it nurtures continual learning and improvement, something that appeals to the core of my being.

Update: Todays The Age has an article encouraging Australian organizations to move IT jobs offshore. While it makes economic sense, it is an uneasy feeling to have your government encourage organizations to diminish your job prospects.

I recently came across some experienced developers that continue to use a trusty text-editor for development purposes.

Now….I can recall the days when I considered auto-completion to be the root of ignorance – how could you possibly learn an API by not referring to its doco? Surely you’d be more encouraged to commit the API to memory without auto-completion? I could always find situations where an editor would automatically do something that wasn’t what I intended – insert spaces here, use tabs there, name variables poorly, place brackets in the wrong location. To cut to the chase, I imagined a plethora of reasons for holding back.

Sure, IDE’s had many drawbacks – 5 year ago. If you hold to these beliefs today, simply put, you’re a dinosaur. IDE’s of today allow developers to reap substantial productivity rewards. They are more configurable and more intelligent, they make class navigation and manipulation a breeze.

Still, hold a discussion with these lads about it and you’d soon delve into an emotion charged discussion, logic and reason taking a back-seat. Somehow it always rose to the top-tier of the NLP rung, like a child feverishly gripping their blankie. To them it was no sweat to ask developers using IDE’s to perform refactorings difficult to express in regular expressions. When pairing with these developers you’d quickly get a feel for how simple activities - like file navigation, refactoring, getting code to compile – were painstakingly drawn out. Clearly the implications of this attitude are more significant on Agile projects.

Much has to be said for allowing developers the freedom to choose their preferred development tools – but I guess this type of freedom implies ’so long as productivity is not compromised’.

Certainly without an IDE productivity is compromised. Please conscientious development teams, veto the use of text editors for development purposes. It should be non-negotiable, no argument could reasonably justify their use. If you continue to use them, I offer some simple advice - evolve or perish.