Testing Google ADK TypeScript Agents Without Flakiness

The fastest way to make an AI-agent test flaky is to assert the final sentence of its response. For instance, when asking an agent to look for hotel options in Paris, the model might return a slightly different conversational phrasing each time. Even though the underlying system behavior is completely correct, the automated test fails red.

Google's Agent Development Kit (ADK) brings agents closer to conventional software engineering by representing agents, tools, orchestration, sessions, events, evaluation, and deployment as code and runtime primitives. This does not magically make the underlying language model deterministic; instead, it provides better architectural places to establish deterministic contracts around it.

Stock photo for illustration only, not from the actual event

Do not test the agent's personality. Test its decisions and execution boundaries. A useful agent test suite relies on four structured layers:

• Small human-reviewed evals
• End-to-end trajectory scenarios
• Runtime contracts: policy, state, and schema
• Deterministic unit tests for tools and adapters

Most tests should live near the bottom of this stack because they are fast, cheap, and strictly deterministic. Live-model evaluations should be used deliberately rather than for every single assertion.

ADK TypeScript tools can be expressed using FunctionTool alongside a Zod parameter schema. The business logic underneath remains ordinary TypeScript and should be tested accordingly. For integration testing, engineers should run the ADK agent, collect its events, and convert framework events into an application-owned summary to prevent tests from coupling to internal event details.

Happy-path prompts alone are never sufficient. Production failures typically lurk at the boundary where a plausible request meets an unsafe action. An ideal safety test passes because an application policy successfully blocked the execution, rather than relying on the model declining it by chance.

When downstream code relies on an agent-produced object, treat it like an external API response. Valuable testing scenarios often emerge from real-world incidents. If an agent selects the wrong tool, duplicates a notification, skips confirmation, or mishandles empty results, developers should preserve a privacy-safe version of that trajectory and add it to a regression dataset.

While ADK's broader tooling supports scoring and evaluation, applications still require explicit pass/fail rules. A single aggregate quality score must never mask a prohibited tool call. Hard constraints should be tracked separately from soft quality metrics:

• Hard: no unauthorized write, valid schema, confirmation preserved
• Soft: relevance, completeness, tone, concision
• Operational: latency, model calls, tool calls, retries, estimated cost

This strict separation makes failures actionable, ensuring that a minor tone regression and an unauthorized booking are handled with appropriate severity levels. Agent testing is ultimately about making the system surrounding the model explicit rather than pretending the model itself is deterministic.

Source: Dev.to