Week 23: Automated Test Framework (ATF) & Unit Testing Scripts

Everything built since Week 4 has been verified by hand — clicking through a form, checking a log statement, impersonating a user. That doesn't scale, and it definitely doesn't survive a refactor unnoticed. This week is about proving your capstone app works without re-testing it manually every time you touch it.

Module 23 of 25 Week 23 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Build an ATF test with UI-driven steps and assertions
  • Write a server-side unit test script exercising GlideRecord logic directly
  • Organize related tests into a Test Suite and explain how ATF fits into a pipeline

1. ATF Tests & Steps

The Automated Test Framework (ATF) drives the actual UI — forms, lists, Service Portal pages — the same way a human tester would, but scripted as a sequence of reusable Steps (Open a form, Set field values, Impersonate a user, Assert a field value) assembled into a Test record, runnable on demand or on a schedule.

conceptual ATF test — equipment request approval flow
Test: "Equipment request auto-approves under stock threshold"
Steps:
  1. Impersonate User: test.requester
  2. Open Form: New Equipment Request
  3. Set Field Values: requested_item = "Monitor", quantity = 1
  4. Submit Form
  5. Assert Field Value: approval_status = "Approved"

Because steps are reusable, building a small library of common steps (log in as a role, navigate to a form, submit) pays off across every test you write after the first few — much like extracting a Script Include pays off across Business Rules.

2. Server-Side Unit Tests

For logic that doesn't need a browser at all — a Script Include method, a Business Rule's core logic extracted into a testable function — ATF also supports server-side test steps that run script directly and assert on the result, closer to a traditional unit test than a UI-driven one:

conceptual server-side test step
var utils = new IncidentUtils();
var count = utils.countOpenByGroup(testGroupSysId);

// ATF assertion step compares 'count' against an expected value,
// configured declaratively in the test step rather than a raw assert() call.

This is exactly why Week 6 emphasized extracting logic into Script Includes instead of writing it inline in Business Rules — a Script Include method is directly, cleanly testable this way; logic buried inline in a Business Rule is much harder to exercise without a full UI-driven test.

3. Test Suites

A Test Suite groups related tests to run together as one unit — all the tests covering your capstone app, for instance — with a single pass/ fail result and a combined execution log, rather than running and checking each test individually every time.

4. ATF as Part of a Pipeline

ATF test suites can be triggered from outside the UI — as part of an Update Set commit, or from an external CI/CD pipeline (Week 24) — so that a change moving from a dev instance toward production automatically runs its test suite first, catching regressions before they reach users rather than after.

5. Hands-on Exercise

Hands-on

Write ATF coverage for your capstone's core logic

Requirements:

  1. Build a UI-driven ATF test that impersonates a test user, submits a new equipment request through a form, and asserts the record was created with the expected field values.
  2. Build a server-side ATF test step exercising any Script Include method you've written for the capstone so far (or build a simple one now, e.g. a stock-check helper), asserting its return value directly.
  3. Group both into a Test Suite named after your capstone app.
  4. Run the suite, confirm both tests pass, then deliberately break one piece of logic and confirm the suite correctly reports a failure.
Hint

Run your test suite before and after any nontrivial change to the capstone from Week 25 onward — that's the actual payoff of building this coverage now rather than treating it as a one-off exercise.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

How does an ATF test differ from manually clicking through a form to check behavior?

An ATF test scripts the same UI-driven interactions — opening forms, setting field values, submitting, asserting results — as a reusable, repeatable Test record built from Steps, so it can be re-run on demand or on a schedule without a human re-performing the same manual clicks every time.

Q2

Why does extracting logic into a Script Include (Week 6) make it easier to test with ATF?

A Script Include method can be exercised directly by a server-side ATF test step, calling it and asserting on its return value — closer to a traditional unit test. Logic left inline inside a Business Rule is much harder to exercise in isolation without a full UI-driven test reproducing the exact conditions that trigger the rule.

Q3

What does a Test Suite provide beyond a collection of individual tests?

A single pass/fail result and combined execution log for a group of related tests run together as one unit — useful for covering everything relevant to one app or feature area without manually running and checking each test separately every time.

Q4

How does ATF fit into a CI/CD pipeline?

A Test Suite can be triggered automatically as part of an Update Set commit or from an external CI/CD pipeline, so a change moving from a dev instance toward production runs its tests first — catching regressions before they reach users, rather than discovering them after a change is already live.