Taking a slightly broader perspective, automated acceptance tests are like any other automated tests -- they should be stored in your version control system and executed periodically on your continuous-integration (CI) server (at least on a nightly basis, but preferably whenever a change is made to the application source code). Getting fast feedback when acceptance tests fail is essential. You can also configure your CI server to publish the results of the acceptance tests where they can be easily consulted by nondevelopers. Fortunately, modern CI tools such as Jenkins integrate well with virtually all of the common BDD tools.
Automating acceptance tests for Web applications
When it comes to implementing ATDD for a Web application, a wide range of open source and commercial tools is available. Given this wide range, choosing your tool with care is important; it can mean the difference between a set of automated acceptance tests that is easy to maintain in the future, and one that quickly becomes unusable due to prohibitive maintenance costs.
Modern automated Web-testing tools, both commercial and open source, fall into three categories:
- Page objects
Record/replay tools, such Selenium IDE and JAutomate, let a user step through a Web application, recording the user's actions as a test script. Although tempting in its simplicity, this approach is in fact a poor strategy. The low-level scripts generated by these tools are fragile and hard to maintain. For example, there is no reuse of testing logic between scripts, which makes maintaining the scripts very costly.
Script-based testing support a slightly more flexible strategy. Tools such as Selenium, Watir, Canoo WebTest, and the commercial Quick Test Pro fall into this category, using tests written in a programming language such as Java, Ruby, or VBScript. However this strategy is still quite low-level, focusing on the technical details of the Web tests rather than the business requirements that they are testing. It also requires strong discipline and structure to avoid duplication within the scripts. Again, this tends to make tests more fragile and harder to maintain.
Good automated acceptance tests should be high-level, expressed in business terms. They need to isolate the what from the how. Doing so ensures that, if the implementation details for a particular screen should change, the changes would only minimally affect the low-level test code and not affect the high-level tests. Ideally, you want to maintain a level of abstraction between what a Web page does in business terms ("Approve an invoice") and how it does it ("Click the invoice in the invoice list, wait for the details to appear, then click on the Approve button").
The page-objects pattern, well supported by Selenium 2/WebDriver in particular, is an excellent choice for ATDD tests. High-level acceptance criteria need to be expressed in high-level business terms (the what), and then implemented under the hood using a set of well-structured, maintainable page objects. For example, an automated acceptance test is expressed in business terms and implemented as a series of steps. Each step uses page objects to interact with the Web application. These levels of abstraction make the acceptance tests considerably more stable and maintainable.