Selenium is a widely-used and very useful tool for automated web testing. This article is a very short primer designed to get you up and running Selenium Tests in Groovy in your Maven projects.

Most people would agree that testing your code is a good thing. And there is little doubt that modern Test-Driven development practices, when applied well, can produce high quality software that is reliable, flexible and easy to maintain. However, one of the big problems that often happens when developers adopt Test-Driven Development is that they concentrate so much on the tests that they lose focus on what they are actually meant to be testing. This results in writing large numbers of superficial and inefficient tests, without testing the underlying user requirements in any real depth.

Behaviour-Driven Development, or BDD, is considered by many to be a natural extention of Test-Driven Development (or TDD). Test-Driven Development is about designing software with the tests in mind.This tends to make the detailed design of your classes cleaner, more modular and more flexible. In practice, it involves writing your tests at the same time as your code - before, simultaneously or slightly after. As a bonus, if you do it well, you get a high degree of test coverage and a good set of regression tests into the bargin.

In a well-organized build process, you want lightning-fast unit tests to run first, and provide whatever feedback they can very quickly. A nice way to do this is to be able to class your tests into different categories. For example, this can make it easier to distinguish between faster running unit tests, and slower tests such as integration, performance, load or acceptance tests. This feature exists in TestNG, but, until recently, not in JUnit.

Indeed, this has been missing from the JUnit world for a long time. Using JUnit, I typically use test names (integration tests end in 'IntegrationTest', for example) or packages to identify different types of test. It is easy to configure a build script using Maven or Ant to run different types of test at different points in the build lifecycle. However it would be nice to be able to do this in a more elegant manner.

View the article...