TESTING & EDITORIAL METHOD

What we test, and what we do not claim.

A useful validator should make its boundary visible. This page records how Guagua Tools separates deterministic checks from judgment, how examples are constructed, and what evidence supports a field note.

1. Start with a reproducible fixture

Every example begins with a complete, copyable input. Hostnames use reserved or fictional examples, credentials use environment-variable placeholders, and expected output is shown beside the input. A fixture should be small enough that a reader can identify the exact field responsible for a result.

2. Trace the implementation

Converter claims are checked against the parser, normalization, validation, and serialization paths in source. Validator claims are classified as schema errors, protocol requirements, interoperability warnings, or security review prompts. Project-specific warnings are not described as requirements from an external standard.

3. Test failure paths, not only the happy path

Examples include malformed wrappers, conflicting transports, unsafe literal credentials, mismatched identifiers, missing discovery links, and unsupported values. The expected behavior includes whether conversion stops, produces a warning, or preserves an unknown field.

4. Keep sensitive material out

No live API key, OAuth token, internal hostname, customer configuration, or private repository is used in a published fixture. Browser-local processing reduces collection risk, but readers are still told not to paste production secrets into any tool.

5. Record the boundary

A static check cannot prove that a remote service is reachable, a package is trustworthy, an OAuth issuer will mint the intended audience, or a generated config works in every client version. Each guide ends with a runtime verification step because syntax is only one part of interoperability.

6. Date and correct the material

Substantive guides display a reviewed or tested date. When protocol behavior changes, the implementation and the related field note should be updated together. Corrections are accepted through the public repository or the contact page; safety and compatibility errors take priority over stylistic edits.

Current evidence notes

• MCP config conversion cases: field preservation, remote bearer tokens, invalid wrappers, and conflicting transports.
• MCP OAuth 401 fixture: challenge discovery, protected-resource metadata, issuer linkage, and audience checks.

Method version 1.0 · Published August 10, 2026