This blog post covers the required implementation to get started with writing Acceptance Tests in a real Java project with JBehave.
Acceptance software testing
In this blog post, Alister Scott explains why it might be better to write acceptance tests in a different language than your code.
This blog post presents the summary of two workshops that aimed at collaboratively creating the ATDD community of practice pattern language.
An interesting posts about how a tester collaborate with the product owner in an agile team to define the acceptance tests.
Many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly. This post explains the principle of symmetric change: one small change in a business model should require one small change to executable specifications.
One of the biggest benefits from acceptance testing for me was that the teams finally get a source of information on what goes on in the system as reliable as the code itself. Without acceptance tests, code is the only thing you can really trust and any other documentation gets outdated very quickly. Acceptance tests stay relevant throughout the project because they are automated, and automated tests are kept up to date in order for them to pass. Automation, and consequently a tool, are necessary to get this benefit.