Tests executed by hand can end up with plethora of results ranging from "*#$& exception!!" to "it works... and this exception has always been there". In case of automated tests things look different. There are only few possible outcomes. Let us take a closer look at them.

Oldest developers can't recall the times when TestNG introduced timeout constraints for tests methods (invocationTimeOut parameter of @Test annotation). The current beta of TestNG allows to set timeouts also for configuration methods.

If you use Eclipse & TestNG you might be interested in these two simple code templates that will help you to create DataProviders.

This is a review of "Growing Object-Oriented Software Guided by Tests" book by Steve Freeman and Nat Pryce (Addison Wesley, 2009)

This book is so great that I could write tons about it, but I tried to keep it reasonably short. :)

TestNG reports can be customized, so any style modification is possible. Did you know there is this nice ReportNG project, that makes TestNG produce very good looking reports without much trouble ?

In your opinion, the original reports of TestNG are (pick one or more options):

1. showing too much information,
2. showing not enough information,
3. not showing what you want to show,
4. require too many clicks to find out what has gone wrong,
5. not very pretty,

Because of this, you finally decide to create your own reports. Good, then read this post, and you will learn about one possible way of achieving this.

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.

Gradle 0.6 was released today ! Among other stuff Gradle now supports execution of TestNG tests.

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.