An acceptance test focuses on a feature and deals with the software like a black box. It just makes sure that the software really does what it is supposed to do, using the same media as that of the users, and observes application output. These tests are sometimes written out of the ordinary development cycle to validate that the application meets defined requirements. They are usually run as a checklist over the software. Often, these tests are not done through TDD, and are built by managers, QA staff, or even customers. In that case, they are often called user acceptance tests.
Still, they can and they should be done with TDD principles in mind. Acceptance tests can be provided before the features are written. Developers get a pile of acceptance tests, usually made out of the functional specifications, and their job is to make sure the code will pass all of them.
The tools that are used to write these tests depend on the user interface the software provides. Some popular tools used by Python developers are shown in the following table:
|
Application type |
Tool |
|
Web application |
Selenium (for Web UI with JavaScript) |
|
Web application |
zope.testbrowser (doesn't test JS) |
|
WSGI application |
paste.test.fixture (doesn't test JS) |
|
Gnome desktop application |
dogtail |
|
Win32 desktop application |
pywinauto |