If you've ever spent a morning staring at raw test logs trying to figure out why a business rule broke overnight, you already know the cost of reactive testing. During a recent Platform Academy session on Agentic ATF, I walked through two capabilities that I think fundamentally change that experience: ATF Code Coverage and the ATF Test Troubleshooting Agent. Together, they shift ATF from something you use to check a box into something that actively works for you.
The numbers behind the problem are pretty striking. Every developer spends roughly 30 to 40 percent of their time debugging rather than building. That's not a small inefficiency. It compounds across sprints, across teams, and across release cycles. And when testing is involved, the cost multiplies: you write the test, the test fails, and then you spend hours manually cross-referencing server logs, client logs, and snapshot diffs trying to reconstruct what went wrong. For many teams, the outcome isn't a fix. It's escalation, or worse, the test gets disabled because the debugging cost is too high.
I wanted to address two specific pain points that came through clearly in our session poll. First, most organizations have no formal way to measure whether their tests are actually covering the code that matters. The vast majority of attendees rely on pass/fail results alone, with no visibility into which code paths their tests are actually exercising. Second, debugging failing tests is the second most painful part of the ATF experience, right behind writing and maintaining the test scripts themselves. Both of these problems are solvable now.
Capability One: ATF Code Coverage
Code coverage is a concept well-established in traditional software engineering, but it hasn't had a native, visual home inside the Now Platform until now. ATF Code Coverage gives you line-by-line execution tracking for server-side scripts as your tests run, so you can see exactly which lines were executed and which were not.
The interface is designed to be immediately readable. Lines that were executed during your test run appear highlighted in green. Lines that were not executed appear in red. This works across the script types you're most likely to be testing: business rules, script includes at the method level, client scripts, and UI actions. You're not getting a single aggregate number. You're getting a precise, visual map of where your tests go and where they don't.
What this unlocks: Before Code Coverage, test quality was largely a matter of judgment. With it, you get evidence. You can identify dead code that was never tested, spot gaps in error-handling paths, and prioritize where to invest your test development efforts based on actual data rather than assumption.
For teams running CI/CD pipelines, there's a REST API available for Code Coverage that lets you pull coverage data directly into your deployment pipeline. This opens the door to automated quality gates: you can define a coverage threshold and fail a deployment automatically if the results don't meet it. That's a meaningful step toward treating test coverage as a first-class requirement, not an afterthought.
One thing I want to highlight because it tends to come up in Q&A: Code Coverage is available from the Australia release onwards and requires no additional licensing. You do need to enable a system property to activate it. Set x_snc_atf_code_coverage_enabled to true and you're ready to go.
Setup requirement: Enable the system property x_snc_atf_code_coverage_enabled = true. No additional license is needed. Available from the Australia release onwards.
Capability Two: The ATF Test Troubleshooting Agent
The second capability is where the agentic piece of "Agentic ATF" really comes to life. When a test fails, the ATF Test Troubleshooting Agent steps in autonomously to figure out why. It examines server logs, client logs, test step snapshots, and metadata differences, then delivers a root cause analysis in plain, developer-friendly language, typically within 30 seconds.
This matters because the traditional alternative is a manual forensics exercise. You pull up logs, compare before and after snapshots, look for what changed, try to reproduce the failure, and often end up asking a more senior developer to take a look. That process can burn hours. The troubleshooting agent compresses it into half a minute and hands you not just the diagnosis but step-by-step remediation guidance tailored to what it found.
"You don't have to ignore it and hope no one notices. That's the whole point of this troubleshooting agent: do what you love best, building, not debugging."
I want to be clear about the design philosophy here. This is a human-in-the-loop experience. The agent surfaces context and recommendations; the developer makes the decision and applies the fix. You're not handing off control. You're getting an expert second opinion in seconds instead of hours.
Requirements: The ATF Test Troubleshooting Agent requires a Creator Pro Plus license, the Generative AI Controller plugin, and Now Platform release Zurich Z5 or above.
Putting the Two Capabilities Together
Code Coverage and the Troubleshooting Agent solve adjacent problems, and they're most powerful when you think about them as a pair. As I put it during the session:
"Code coverage gives you evidence-based confidence in test quality. The troubleshooting agent helps you with debugging, from hours to seconds. Together these tools help you evolve your ATF from a reactive tool to an intelligent tool."
There are a few use case patterns worth calling out specifically, because they came up in discussion and I think they represent the most practical entry points for teams at different stages of ATF maturity.
Parameterized tests combined with Code Coverage
If you're already writing parameterized tests that exercise a function with multiple input variations, Code Coverage lets you visualize which inputs are reaching which code paths. You stop guessing about edge case coverage and start seeing it directly.
Nightly regression tests with the Troubleshooting Agent
Schedule your regression suite to run overnight and configure the Troubleshooting Agent to analyze any failures. Your team starts the morning with root causes and recommended fixes already waiting for them, not raw logs and a debugging session on the calendar.
Coverage REST API as a CI/CD quality gate
Pull Code Coverage results into your deployment pipeline via the REST API and set a coverage threshold that must be met before a deployment proceeds. This moves test quality from a manual review concern to an automated, enforced standard built directly into your release process.
ATF Code Coverage as a CI/CD Quality Gate
|
💻
Code Change
Committed |
→
|
🧪
ATF Test
Suite Runs |
→
|
📊
Coverage Pulled
via REST API |
→
|
🔒
Quality Gate
Evaluated |
→
|
❓
Pass or
Block? |
|
Coverage meets threshold
✓ Deployment Proceeds
|
Coverage drops below threshold
✗ Deployment Blocked
|
Getting Started
If you're ready to explore these capabilities, here's a practical sequence to follow:
- Always work in a non-production instance. This is a firm rule for ATF regardless of which capabilities you're using. Never run ATF tests against production. Start in a sandbox or sub-production environment where you can experiment safely.
- Enable Code Coverage via the system property. If you are on the Australia release or later, set
x_snc_atf_code_coverage_enabled = truein your non-production instance and run an existing test suite against a business rule or script include. The visual output is immediately readable, and seeing real gaps in your coverage is usually motivating in a useful way. - Check your license and plugin status for the Troubleshooting Agent. If your organization has a Creator Pro Plus license and is running Zurich Z5 or later, verify that the Generative AI Controller plugin is active. The agent is available to use once those prerequisites are in place.
- Watch the full demo. The session recording includes complete walkthroughs of both capabilities in action. Seeing the tools in context makes a real difference, especially for the Troubleshooting Agent's output format.
One thing that came through clearly in the session Q&A is that ATF plugins behave consistently in cloned instances, so if your team uses instance cloning as part of your testing workflow, you won't see unexpected differences in how these features behave after a clone.
Watch the Full Session
The complete Platform Academy session on Agentic ATF, including live demos of both Code Coverage and the Test Troubleshooting Agent, is available on YouTube. If your team is evaluating either capability, the demos are worth watching before you start your configuration.
Questions or feedback? Drop them in the comments below. I read every one.
