2

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.

Improve this question
1
  • Sounds like you need to work out your hierarchy of specifications.
    – quickly_now
    Commented Jun 27, 2011 at 5:58

2 Answers 2

Reset to default
5

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.

Improve this answer
4
  • 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
    Commented Jun 27, 2011 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 ♦
    Commented Jun 27, 2011 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).
    – quickly_now
    Commented Jun 27, 2011 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
    Commented Jun 27, 2011 at 13:06
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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