The pain of redeploying makes for better TDD

Dions thought provoking blog entry on Refactoring tools are fantastic and overrated inspired me to think more in-depth about the deploy/redeploy nature of Java web development. He makes the point that while tools like IDEA have great refactoring, that other factors such as the pain of constantly redeploying in Java containers outweighs the benefits of these tools. I totally agree in theory, however, in practice I've found that the pain of redeploying has a very nice side benefit (at least for me).

Before I go any further let me add that we develop in Tomcat with class reloading enabled so when you change a class you just hit refresh in the browser. However, as Dion points out that doesn't solve non-trivial changes such as configuration changes which do require a Tomcat reload.

Anyhow, to my point, I personally like the pain of redeploying because it forces me to develop using TDD for just about everything up to and including the controller. Then I generally just make minor code tweaks and the HTML changes in a live Tomcat (where a simple browser refresh will give me the feedback). If a bigger code change is involved I go back to TDD to drive the controller or business logic until I get them working as desired.

On the other hand with Ruby and Perl I often find myself starting to get lazy by developing from a page centric point of view because it's much easier to just hit refresh in the browser. It's easy to get carried away by relying on the browser for the feedback, even as deeper business logic changes creep into the picture. When this happens I come back after an hour of coding only to realize I now have a bunch of out of date unit tests that need to be updated and the test coverage is never quite as good then.

Maybe it's just me, but since TDD is so much easier than constantly redeploying I actually practice better TDD under Java than I do in Ruby.

This entry was posted in Java. Bookmark the permalink.