ATF test suites
Write tests that survive upgrades: test steps, suites, scheduling, and the rules that keep ATF trustworthy.
Write tests that survive upgrades: test steps, suites, scheduling, and the rules that keep ATF trustworthy.
- ATF is for sub production only
- Impersonation makes tests reflect real permissions
- Tests should create the data they need
- A suite that is always red teaches the team to ignore it
What ATF tests
ATF drives the UI and the server: open a form, set fields, submit, assert a field value, run a server side script and check the result. It is the practical way to prove that an upgrade or a release did not break your critical paths.
Structure
A test is a sequence of steps. A test suite groups tests and can run nested suites. Schedule suites to run nightly in development and on demand before a release.
Rules that keep it useful
Most ATF disappointment comes from ignoring these.
- Never run ATF in production, it creates and modifies real records
- Use the impersonate step so tests reflect real user roles
- Create your own test data in the test rather than relying on demo records
- Keep tests short and focused so a failure names the problem
- Quarantine flaky tests immediately, a red suite everyone ignores is worthless
Upgrade value
Run the suite before the upgrade to get a baseline, then again after. The difference is your regression list, and it turns an upgrade argument into a short factual conversation.