This is a continuation of the post devoted to some code smells that was vigorously commented in favour of ugly, anti-OO code design :). Thanks God, I also got an interesting question regarding this problem.

Seems to me, that this topic should be discussed one more time.

This is a part of "Ant/Gradle/Maven comparison" series.

A common task during development is the creation of an installable version of software. The one I mention in this post is a real one - this is something I've been working working with since few months. It does few things related to Fuse ESB:

• unpacks Fuse sources,
• updates some config files,
• retrieves few JARs from Maven repository and put them into deploy folder,
• does some more file-related stuff - creates directories and copies files,
• produces ready-to-unpack-and-use file: tar.gz (for Linux) and zip (for Windows).

I started to write this with Ant/Maven, and then switched to Gradle. I'll present few code snippets here, that should give you a decent understanding of difference that Gradle makes. Please judge for yourself if the switch from Ant/Maven to Gradle was worth the effort.

Is test-first better than test-last ? Is there a significant difference in the quality of code developed using these approaches ? It's hard to say for sure. My gut feeling (and experience) tells me that test-first is superior. Sometimes I find evidences for this claim. Like the one I present in this blog post.

So you decided to check some build prerequisites before doing any real job. You want to check if proper Java version is installed, if some configuration files are available etc.

I'll show you how you can do this using Ant, Gradle and Maven.

Are you using Maven ? Or maybe you hate Maven and you still use Ant ? Or maybe you feel that both are not enough and you are looking for something else. Than look no more, cause Gradle offers what you need.

Today I played with unique IDs generator. While doing this, I have found how very useful is one of the features of TestNG framework - its ability to run tests in parallel.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JtestR library to write test cases... well, not exactly. The point is that you can't do it with JtestR. :(

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JMockit library to write test cases.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JEasyTest library to write test cases.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. This part will show how we can make testing possible thanks to some design sacrifices.