Brain Dead Development against the curse of the Servlet

In the last two years, I have found it increasingly difficult to write code in a non TDD approach. Tests think for you. They dictate how actual code is going to be laid out, they take you by the hand and show you the way (Hmmm… ApocalypticTesting?..). It’s strange how things become so much clearer when I’m in the testShouldRockWithAGibson() path of thinking. It actually feels like I have to think less.

Hence Brain Dead Development (BDD). This is by no means coined as a derogatory term, I mostly went with it because it sounds sounds funnier than, say, Thought Process Enhancing Development, and term hunting is hardly my number one favorable activity anyway. Because tests do point out the solution. Or rather, make you ask the right questions, so that you realize the answers and solve the problems at hand sooner. And then you’re either going to impress your PMs and IMs with your agility and your velocity and productivity, or wait it out for the full length of the initial estimation for the task, read blogs and carefully plan a day for the purchase of a black MacBook. Or should you go white?..

I have found myself in situations where the main thing I have to concentrate on is come up with meaningful class and method names and ways to make the codebase more elegant, readable and effective. Everything else just sort of falls into place by keying [alt-Enter], [ctrl-alt-f] and a few other IDE key combinations. Add pair programming to the mix, ping pong the keyboard between the dev who writes the test and the dev who makes it pass and we could be talking serious fun here. Mention must also be given to the incredible sense of confidence a thoroughly tested application will offer, as you know that if you do something wrong, someone’s going to ring the alarm on time, before things get out of hand and certainly before an unnoticed bug makes it into production.

Attention to the way your tests look and behave will enforce good coding practices and will reveal structural code smells early on. You just know that when you have to mock 5 interfaces in one unit test it’s time to revise your strategy and rethink your Class structures and behavior. And if it’s time to import the cglib JMock library, then, man, you’re asking for it.

I know many people are practicing TDD every day, and I sense TDD is going to become a de facto practice for Agile and Waterfall type of evangelists alike very soon. This is why sometimes I’m surprised by the fact that there isn’t as of yet any significant movement away from Servlets, an API so crooked that it is almost impossible to test drive. Even WebWork, ‘the least worse Java web framework’ merely hides the Servlet ugliness, which is already a move towards the right direction, but certainly not enough and maybe too little too late.

Article on Java’s demise due to weight problems coming soon. Obviously…

Comments are closed.