Testing

Testing explains the quality layer of MTPX with practical guidance for building inspectable, tool-using agents.

Testing

Chapter 020ReleaseQualityIndex

01Orientation

Testing belongs to the release track. The page breaks the idea into responsibilities, implementation rules, failure modes, and the signals you should expose in a product UI.

Use this when

Use this when you need to understand how testing affects a real MTPX agent before you wire it into an application.

What testing owns in the runtime.
How it connects to planning, tool execution, events, providers, or storage.
What to log, test, and expose to users when this layer is active.
Common mistakes that make agent systems hard to inspect.

02 / syntax starter

from mtp import Agent
from mtp.providers import Groq

agent = Agent.MTPAgent(provider=Groq(), tools=tools)
print(agent.run("Testing: explain the next runtime step.", max_rounds=4))

03 / manual

Read the system

The complete source manual—syntax, examples, linked references, edge cases, and implementation notes.

Documentation index ↗

01Test tiers

This project separates tests into tiers so mixed environments are more reliable.

Test tiers

fast unit tests: deterministic, local-only, no live provider requirements
integration tests: transport/socket/conformance style tests
live tests: real external provider/network credentials (opt-in)

Markers:

integration
live

02Recommended local commands

Recommended local commands

Run fast tests only:

bashpytest -q -m "not integration and not live"

Run integration tests:

bashpytest -q -m "integration and not live"

Run everything except live:

bashpytest -q -m "not live"

03Reliability notes

Reliability notes

pytest.ini enforces:
--strict-markers
workspace-local base temp root (tmp/pytest_tmp)
collection hygiene (norecursedirs ignores transient and lock-prone paths)
tests should prefer workspace temp roots (tmp/...) over OS global temp paths
cleanup logic should be permission-aware and retry-safe on Windows/sandboxed filesystems
network/server startup checks should use wait loops instead of fixed sleeps where possible

04CI parity

CI parity

CI runs:

fast tests on ubuntu, windows, macos
integration tests on representative ubuntu + windows

This catches common path/permission/socket differences early.

Read

Understand where Testing sits in the agent loop before adding abstractions.

Wire

Connect the smallest useful provider, registry, store, or event stream first.

Observe

Expose events, logs, results, and failure states while the runtime is still moving.

Harden

Add policy, tests, retries, and audit traces after the behavior is visible.

Next docMTP Native Tool Call Syntax