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? In this article, we look at how to obtain test data from an Excel spreadsheet.

I don't unit test my classes. I don't even unit-test my methods. You'll be hard-put to find the word "test" in my source code. And I never, ever create a new JUnit Test Case Eclipse.

I prefer to test how my application behaves. And I find it makes a huge difference.

People often confuse performance and scalability testing, but they are actually quite different activities. Performance testing involves ensuring that your application responds to requests within an acceptable timeframe. Of course, defining what "acceptable" is is a fine art, and perceived performance (what the user actually sees) is often more important than real performance.

Recently I had the pleasure of giving a talk at the Canberra Java Users Group on the topic 'Real Developers Don't Need Unit Tests':

"Unit testing, and Test-Driven Development in particular, is a vital but neglected art. Proper TDD don't just test code: your tests are executable requirements that tell the story of your application, clarify your design, document your code and help track your progress. They help you find bugs fast, and fix them with confidence. If Real programmers don't need unit tests, they sure make life easier for the rest of us!"

I've posed the slides for this presentation in this article.

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? (By legacy code, I mean any code that does not have a comprehensive set of automated tests, so you might be writing legacy code as we speak). For most of us, most of the code we will ever work on will not have originally been our own work. And, unfortunately for the software industry, only a small fraction of code can really boast comprehensive unit and integration tests. How can techniques like Test-Driven Development make our work as developers more productive and less frustrating?