Featured White Papers

• Utilizing Fast Testing to Transform Java Development
• 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

Selenium 2 and Thucydides for ATDD

From automated web tests to automated acceptance criteria

By John Ferguson Smart, JavaWorld.com, 10/18/11

John Ferguson Smart is an advocate of open source tools that support and automate the software development lifecycle, especially in Agile environments. Now he presents Thucydides, his own testing library built on top of Selenium 2/WebDriver. As he demonstrates, Thucydides rethinks and extends the potential of ATDD; first by turning automated web tests into automated acceptance criteria, and then by documenting that criteria for collaborative, multidisciplinary teams.

Acceptance test driven development, or ATDD, is a collaborative practice where users, testers, and developers define automated acceptance criteria early in the development process. The team then uses that criteria to guide subsequent design and coding. The acceptance criteria document a common understanding of the problem domain and its proposed solution. In multidisciplinary teams, such documentation helps to ensure that everyone agrees about a project's requirements and implementation. When acceptance criteria are automated, they become part of the "living documentation" of the system, always accurate and up to date.

If you are writing a web application, it makes sense to have your automated acceptance tests exercise the application as a user would, via a web interface. Many web testing libraries do just that, including open source tools such as Selenium, Canoo WebTest, WebDriver, and the recent Selenium-WebDriver integration, Selenium 2. These tools focus on testing the details of web page interaction, and they're great at that.

Most automated acceptance tests do not completely fulfill their potential, however, in that they do not drive the development and documentation process as much as they could. As a proponent and practitioner of test-driven development and other lean, collaborative development methodologies, I wanted a testing framework that would let me express and report on acceptance tests at a high level, group tests by stories and features, and then drill down into the details as required. And so I created one.

In this article I introduce Thucydides, an open source ATDD framework built on top of Selenium 2.

Introducing Thucydides

Thucydides is a software testing library designed to help developers write automated acceptance tests and web-based automated acceptance criteria. Thucydides provides extensions and utilities that improve web testing and development on Selenium 2 in three ways:

1. Organizing web tests into reusable steps, and mapping them back to their original requirements and user stories.
2. Generating reports and documentation about acceptance tests. Each report contains a narrative description of a given test, including a short comment and screenshot for each step. Reports serve as living documentation, illustrating how an application implements the specified requirements.
3. Providing high-level summaries and aggregations in each report. These give an overview of how many stories and requirements have been tested by automated acceptance tests, which in turn lets developers gauge the relative complexity of each story.

Different stakeholders need to be able to view acceptance test at different levels. For instance, a developer needs to know how a feature should interact from the perspective of the end user. This will start at a high level, expressing the general business goals behind a feature, but during the development process the developer will progressively drill down until she is specifying detailed page-level interactions.