A user story cannot stand alone, however; it is merely the promise of a conversation between developers and users about a particular requirement. The details about what needs to be implemented will arise from this conversation. It will then be formalized as a set of objective, demonstrable acceptance criteria. For example, you would need to specify acceptance criteria for "user can approve an invoice for an amount less than the agreed maximum" and "user cannot approve an invoice if the price exceeds the agreed maximum."
Acceptance criteria determine when a particular user story is ready to be deployed into production. But they do much more than record what should be tested at the end of an iteration. Acceptance criteria are drawn up as a collaborative exercise, at the start of the iteration, with developers, testers, and product owners involved. As a result, they help ensure that everyone on the team has a clear vision of what is required. They also help provide clear guidelines for developers as to what needs to be implemented. (These guidelines are even more effective if the developers doing the programming are practicing test-driven development, or TDD.)
Note that acceptance criteria are not designed to be exhaustive -- there will be more technical tests for that. Instead, they are used as much for communication as they are for verification. They take the form of working examples, which is why ATDD is sometimes referred to as "specification by example."
Acceptance-test-driven development is not just limited to agile projects. Even teams using more formal and detailed use cases, or more traditional approaches such as the software requirements specification (or SRS) documents, can benefit from having verifiable, automated acceptance criteria as early as possible.
Automating your acceptance tests
A key part of acceptance criteria is that they are automated. They are not simply stored in a Word document or Excel spreadsheet; instead, they are living, executable tests. This is important -- for ATDD to be effective, the automated acceptance tests need to be run automatically whenever a change is made to the source code. So it is vitally important to have a tool that will integrate smoothly into your build process and that can be run on your build server with no human intervention.
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 head's-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 several dedicated ATDD tools. These tools are focused as much on communication and feedback as they are on testing.
ATDD is more an approach than a toolset, but there are several tools that can make things easier.