I'm starting to get into writing automated Acceptance tests and I'm quite confused where to write these tests against, specifically what layer in the app. Most examples I've seen are Acceptance tests written against the Domain but how about tests like:

Given Incorrect Data When the user submits the form Then Play an Error Beep

These seem to be fit for the UI and not for the Domain, or probably even the Service layer.

  • Sounds like you need to work out your hierarchy of specifications. Jun 27 '11 at 5:58

Typically, an acceptance test is written against a requirement. Regardless of how you capture requirements, you should have a set of things that your system must be able to do, expressed as a list in an Software Requirements Specification (SRS) or as a collection of user stories, among other options. Each requirement should have an acceptance test associated with it that is run against the system that builds and runs.

Acceptance tests come after unit testing (which typically tests at the function, method, and class level), integration testing (class and package level), and system testing (post-integration to ensure that the system functions as designed). After system testing, the developing organization knows that the software works as they intended it. Acceptance testing ensures that the needs of the client/user are fulfilled as specified by the known requirements.

  • You mean to say that acceptance testing is of a higher level than those other tests right? Does this mean that it's run on the highest possible layer (i.e. the UI?) or that it isn't bound to any layer at all and is written against wherever the implementation to that requirement is found?
    – Jonn
    Jun 27 '11 at 2:05
  • It isn't bound to any layer. You test the requirement against where ever that requirement exists. In many cases, you'll be testing multiple layers simultaneously, though, since the requirement describes the system as a whole (which, by definition, includes all layers).
    – Thomas Owens
    Jun 27 '11 at 2:10
  • 4
    Imagine that the acceptance test is run with the customer witnessing it, and he won't pay you the final project progress payment until it is done, and until everything passes. Once it all passes, the client is happy, pays the last of the money, and the project is closed. (I'm aware that reality often differs, but contract project delivery in s/w and engineering frequently works like this). Jun 27 '11 at 5:56
  • I see. This explains a lot of things for me. I've always wondered what the relevance of the testing frameworks similar to Selenium are when most of my Unit Tests are locked onto the domain.
    – Jonn
    Jun 27 '11 at 13:06

Who is really supposed to accept your delivery ? Answer on that question will help you determine how to structure your Acceptance tests.

Better still - involve them (customers, customer representatives, stakeholders, system tests etc) in writing/defining acceptance tests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.