Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Acceptance test driven development for web applications

ATDD is a simple process change that can have far-reaching implications for your development projects.

By John Ferguson Smart, JavaWorld.com, 08/23/11

Page 3 of 5

Automated acceptance tests not only serve to test the application: they also provide an objective measurement of progress (in agile projects, working software is considered to be the only true measure of progress). The tests can also give an idea of the relative complexity of each feature and story, because a functionality that is long and complicated to test is likely to also be long and complicated to develop. This in turn can give a useful heads-up to product owners needing to set priorities.

Although you certainly can write automated acceptance tests using conventional unit testing tools such as TestNG, there are a number of dedicated ATDD tools. These tools are focused as much on communication and feedback as they are on testing.

ATDD tools

ATDD is more an approach than a toolset, but there are a number of tools that can make things easier.

FitNesse is one of the earliest ATDD tools. Using FitNesse, users enter their requirements in tabular form in a Wiki, and developers write code behind the scenes to run the test data stored in the Wiki against the actual application. When the tests are executed, the table will be colored according to whether the tests succeeded or failed. FitNesse is very useful when your acceptance test criteria can be expressed in terms of tables of data and expected results, although it is also used to express acceptance tests as a series of steps.

More recently, other tools have emerged that support Behaviour-Driven Development, or BDD. This technique encourages developers to think in terms of the behaviour of an application, and to express their low-level technical requirements using a narrative approach. Cucumber is a popular tool from the Ruby community, that allows you to express your acceptance criteria using the "given-when-then" structure commonly used in agile projects. It is also easy to use Cucumber with Java. JBehave uses a similar approach, with stories expressed in text files and tests written using annotated Java classes. Easyb is a similar tool based on the Groovy language.

Concordion is another more recent ATDD tool. In Concordion, acceptance tests are expressed in the form of HTML pages containing free-form text and tables. Java classes are then used to analyze special tags placed in these pages, in order to execute and display the results in HTML form.

All of these tools place a high emphasis on readability and communication. Listing 1 illustrates how one of the earlier acceptance criteria might be expressed using Easyb:

Listing 1. A user scenario in Easyb

scenario User can approve an invoice for an amount less than the agreed maximum"
    {
      given "the User has selected an open invoice",
      and "the User has chosen to approve the invoice",
      and "the invoice amount is less than the agreed maximum amount",
      when "the User completes the action",
      then "the invoice should be successfully approved",
    }

Once the acceptance criteria are defined in this way, the corresponding test code can then be written in more conventional programming languages such as Java, Groovy, and Ruby.