After years of being immersed in Java development, I must admit that I got spoiled by its strong and mature ecosystem. Hence, whenever I want to pick up a new technology or programming language the following must be there:
Support by my favorite IDE (Eclipse or IntelliJ IDEA)
Mature building framework. It does not have to be Maven or Gradle but it needs to be at least better than Ant.
Easy TDD. This could be the trickiest one to achieve because not only do I need a testing framework, but it must also be supported by my IDE and build tool. Moreover, it must have an adequate mocking framework.
Groovy easily satisfies those criteria right out of the box. It has awesome support by IntelliJ IDEA, Gradle is written in Groovy and you can write JUnit 3-style unit tests.
Now we will cover the fun stuff for which we’ve been waiting. In this post, I’ll go over how to setup Sonar for a Java project that utilizes Ant for its build. I’ll go through the basic steps for installing and running a Sonar instance, and how to use a MySQL database for collecting metrics. Then I’ll go into some details around analyzing a Java project using Ant and Sonar. This involves writing Ant script, pointing to the source codes, analyzing the binaries, analyzing JUnit test cases, analyzing Ecl Emma coverage, etc.
I’ve burned myself so many times with dependency injection in the past. It make me nervous when I see a complex software product comprised of multiple projects and dozens of libraries without any comprehensive test that double checks the wiring. As our wiring grows and changes over time we need to continuously verify that everything works together. Dependency injection is one of the most valuable patterns in software development. Spring.NET is a necessity in today’s world and has great power that we need to harness in our products. With software products getting bigger and bigger, Spring.NET turns into a double edged sword that can hurt us especially if we cannot prove that every object is wired properly.
Beanoh.NET is a powerful tool for designing and maintaining Spring.NET configurations. One time I had an object named “messageSender” and that object controlled an HTTP connection to a web service by specifying a timeout for connecting and reading the HTTP stream. One day I needed to up the read timeout but for the life of me I couldn’t figure why the call was timing out after 15 seconds even though I’ve increased the timeout to 30 seconds. I spent hours looking into the documentation of the HTTP sender and debugged the code to no avail. In a moment of despair, I ran an Agent Ransack search through the whole web application package for the word “messageSender” and found two objects with that name one with 15 seconds timeout and the other with 30 seconds timeout. Each pulled from a different library. Wouldn’t it be awesome if my continuous build failed with a message saying “a duplicate object definition was found with the name of ‘messgeSender’. Are you sure you want them overriding each other ? ” If I was using Beanoh.NET it could have identified this duplicate bean.
Once you catch the automated testing itch you want to write test for everything. But should we use the same strategy for every piece of software? The conclusion that I’ve come to is no. While I’m completely committed to the practice of TDD and aggressive test coverage, I’ve found that legacy software needs to be approached strategically. Continue reading →