Quick answer
Passing GTM custom-template unit tests does not prove that live tracking works. Google documents that unit tests do not check field validation rules and that mocked APIs do not perform permission checks. Add separate validation, permission, browser, and destination checks before approving the release. Keep production customer data out of the test fixture.
Write the output contract first
Choose one small behavior to test: for example, converting an approved campaign label into the exact string expected by a tag. Define the allowed input type, missing-value behavior, and output type. A string, array, boolean, and undefined value are not interchangeable simply because a preview panel displays them similarly.
Build fictional fixtures for a valid value, an absent value, an unexpected type, and an intentionally disallowed value. Decide whether each should return a result, stop safely, or report a controlled failure. Do not automatically convert missing data into an empty string if that makes downstream tags send misleading events.
State what mocks are substituting
For every mocked API, list the real dependency it replaces. A mocked data-layer read might bypass permission behavior. A mocked network API cannot prove the browser connected to the approved host. A mocked success callback cannot prove the destination stored anything.
Keep unit tests focused on the logic they actually cover. Add explicit tests for failure and missing-input branches rather than one happy-path assertion. When a test passes, describe it as a logic result under the supplied fixture, not a full integration certification.
Test configuration and permission separately
Use the template's supported manual validation workflow for its fields, then review the requested permission patterns against the actual resources needed. A broad wildcard is not an acceptable fix for an unexplained denied request. Test the intended allowed resource and a deliberately out-of-scope resource in a controlled environment.
Record the template version, field values, and permission configuration used in the test. A developer may test one workspace while the site loads an older published container. Comparing those versions early avoids spending time investigating a browser that never received the change.
Trace the browser execution
On a staging page, use a fictional event and the real consent manager state. Follow the trigger, variable output, tag execution, and resulting request. Inspect the document's security policy if the request is blocked. Template permissions, browser CSP, and consent are separate controls; passing one does not imply the others permit the action.
Repeat the intended denied-consent path. Its expected behavior should follow the implementation's documented policy, not a blanket assumption that every analytics request must behave identically. Do not temporarily grant consent or relax CSP just to produce a green test result.
Layer | Evidence to keep
Logic | fixture and assertion
Configuration| validated fields
Permission | allowed and denied resource
Browser | trigger, output, request
Destination | one accepted fictional event
Confirm the destination outcome
Use the destination's test or debugging facilities to locate the fixture. Check its identifier, event name, timestamp, and expected fields. A browser request can succeed while the destination rejects a field or routes the event to another property. Allow for the destination's documented processing delay without treating an indefinite wait as success.
Count events as well as finding one. A migrated template can run beside the original tag and emit duplicates. Compare the event identifier or a controlled test marker across the old and new paths. Do not leave both enabled merely because each passes independently.
Make release approval reproducible
Keep the exact published version and the results for every layer in one acceptance record. Mark a layer untested when evidence is unavailable. After deployment, verify one harmless production-compatible path and monitor errors. Roll back the specific container change if it violates the contract, while preserving the failing trace for investigation.
Illustrative diagnostic example. Use your own redacted evidence.One final acceptance check
Include the return type in the browser acceptance record. An assertion that a value exists can miss a string-to-array change that breaks the receiving tag. Compare the documented contract at both the variable output and the tag input, using the same fictional fixture.
When to bring in help
Use WordPress tracking implementation support when the template, consent manager, and destination show different results. Bring the published container version and redacted fixture trace, not customer events.
Related troubleshooting
For the adjacent diagnostic path, read GTM template permission migration review. Keep its evidence separate from this test so a change in one component does not hide a failure in another.
Helpful references
GTM template tests. GTM template permissions.