Appreciating Acceptance Testing
One of the most important things I learnt to appreciate during my internship at InishTech is the value of Acceptance Testing.
Let me give a short definition of what I understand Acceptance Testing is:
There are different levels of testing you can do on your project, and they usually differ by the level of abstraction they work at. On the bottom you have Unit tests, tests that cover individual units in isolation. The next level is Integration testing. Integration tests exercise components of a system and usually cover scenarios where external resources are involved. Above that we have Scenario or Acceptance testing. Acceptance testing works at the level a perceived user of your system may operate. If you work in an agile process like we do at InishTech, you can translate each of your User Stories into an Acceptance test that verifies the story has been properly implemented. I don’t want to go deep on differentiating between these levels, he boundaries between them are blurry but all of them have a good raison d’etre.
Writing Acceptance tests is no different from writing any other kind of test. But what makes them so helpful is that they serve as a high level specification for the functionality of your system.
Acceptance tests will help you to:
- Specify the behavior of your system from a user’s perspective
- Make sure that functional requirements are met
- Document expected behavior of your system
- Discover bugs that you may else only find during manual tests
Acceptance tests will not help you to:
- Locate Bugs
The key to success with acceptance testing is to write acceptance tests as declarative as possible: Test what is done instead of how it’s done. If this reminds you of BDD (Behavior-Driven-Design) you are correct, because this is exactly where the drive to acceptance testing comes from.