ATF test suites
Quick answer
Write tests that survive upgrades: test steps, suites, scheduling, and the rules that keep ATF trustworthy.
Key takeaways
- 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.
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Where should ATF suites run?
- A. Production only
- B. Sub production instances
- C. Any instance
- D. Only on the MID server
Show answer
B. Sub production instances
ATF creates data, so it is restricted to non production instances.
Which step makes a test reflect a real user?
- A. Set field values
- B. Impersonate
- C. Open a list
- D. Assert
Show answer
B. Impersonate
Impersonation applies that user roles and ACLs to the test.