One nice feature in JUnit 4 is that of Parameterized Tests, which let you do data-driven testing in JUnit with a minimum of fuss. It's easy enough, and very useful, to set up basic data-driven tests by defining your test data directly in your Java class. But what if you want to get your test data from somewhere else?
Test-Driven Development, or TDD, is often quoted as an essential Agile best practice, and so it is. It works wonders on green-fields projects and new code bases where you can start afresh and ensure that all your code is both easily testable and well tested. But what about legacy code?
I'm very excited about the upcoming Testing and Test-Driven Development for Java Developers 2-day workshop, coming soon to Auckland, Melbourne, and Sydney.
Last time, I introduced some of the new Groovy support available in Maven 3, and looked at how you will be able to write your pom files in Groovy, or in other non-XML notations.
In this edition of the Java Power Tools Newsletter, we will be looking at strategies and tools for developer web testing.
Maven 3 is promising to be the most significant upgrade since the release of Maven 2. While maintaining backward compatibility with existing Maven 2 projects, it introduces a number of powerful and compelling new features, such as a complete rewrite of the internal architecture, OSGi support and multi-language pom files. In this article, I will be giving a preview of this last feature.
A good build script should be self-contained, self-booting and portable. You should be able to check it out of source control and run it. No buts. Period. The rules (or tips) that follow should be self-evident and applied everywhere. Unfortunately, they are not. The following "rules" are based on issues I've encountered in existing real-world build scripts.
I am thrilled to announce that I will be running the 'Testing and TDD for Java Developers' workshop in Melbourne on December 8-9, 2009.