schema_test_implementation_guide

A practical guide for writing Go tests for GoZod schemas, which define and validate the shape and types of data. It covers both flexible runtime parsing and stricter compile-time type checks.

In plain words
What is it for?
Use it when creating or updating schema test files, especially tests for Parse, StrictParse, generic type safety, chained modifiers, Default, Prefault, and error handling.
Why use it?
It gives tests a consistent structure and helps catch incorrect type behavior, modifier handling, defaults, validation boundaries, and edge cases.

Cursor rule for Codex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/kaptinlin/gozod/schema_test_implementation_guide
Clone the repo
git clone --depth 1 https://github.com/kaptinlin/gozod

Made for: Codex.

Per session 4,495 This file is loaded in full into every session.
When invoked 4,495 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.04495 $0.04495
Opus 5 $0.02247 $0.02247
Sonnet 5 $0.00899 $0.00899
Haiku 4.5 $0.00449 $0.00449

Measured 2d ago against content hash ef4557d5b0d4, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

schema_test_implementation_guide scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.agents/rules/schema_test_implementation_guide.mdc · 473 lines

How it starts

The opening of the file, as written. The whole thing — 473 lines — stays where its author put it; the contents beside it link to each section on GitHub.

GoZod Schema Test Implementation Guide

A concise and practical guide for building GoZod Schema test files, updated with the latest practices from string_test.go, object_test.go, and complex_test.go.


🎯 Core Principles

  • Complete Strict Type Semantics: Test both Parse(any) and StrictParse(T) methods thoroughly.
  • Parse vs StrictParse Duality: Verify Parse provides runtime flexibility while StrictParse provides compile-time type safety.
  • Generic Type Safety: All tests must verify compile-time type safety and proper constraint handling.
  • Modifier Behavior: Test immutability, correct type transformations, and Default/Prefault semantics.
  • Comprehensive & Organized: Follow the unified section structure for clarity. Test boundaries and edge cases thoroughly.
  • Real-World Patterns: Tests should reflect actual API usage, including modifier chaining and error handling.
  • Default vs Prefault: Verify Default short-circuits validation while Prefault goes through full parsing pipeline.

🏗️ Test File Architecture

Each test file for a schema type should follow this consolidated architecture based on latest implementations:

package types

// ... imports

// =============================================================================
// Basic functionality tests
// =============================================================================
func Test<Type>_BasicFunctionality(t *testing.T) {
    t.Run("valid <type> inputs", func(t *testing.T) { /* ... */ })
    t.Run("invalid type inputs", func(t *testing.T) { /* ... */ })
    t.Run("Parse and MustParse methods", func(t *testing.T) { /* ... */ })
    t.Run("custom error message", func(t *testing.T) { /* ... */ })
}

// =============================================================================
// StrictParse and MustStrictParse tests
// =============================================================================
func Test<Type>_StrictParse(t *testing.T) {
    t.Run("basic functionality", func(t *testing.T) { /* ... */ })
    t.Run("with validation constraints", func(t *testing.T) { /* ... */ })
    t.Run("with pointer types", func(t *testing.T) { /* ... */ })
    t.Run("with default values", func(t *testing.T) { /* ... */ })
    t.Run("with prefault values", func(t *testing.T) { /* ... */ })
}

func Test<Type>_MustStrictParse(t *testing.T) { /* ... */ }

// =============================================================================
// Type safety tests
// =============================================================================
func Test<Type>_TypeSafety(t *testing.T) { /* ... */ }

// =============================================================================
// Modifier methods tests
// =============================================================================
func Test<Type>_Modifiers(t *testing.T) { /* ... */ }

// =============================================================================
// Chaining tests
// =============================================================================
func Test<Type>_Chaining(t *testing.T) { /* ... */ }

// =============================================================================
// Default and prefault tests
// =============================================================================
func Test<Type>_DefaultAndPrefault(t *testing.T) {
    t.Run("Default has higher priority than Prefault", func(t *testing.T) { /* ... */ })
    t.Run("Default short-circuits validation", func(t *testing.T) { /* ... */ })
    t.Run("Prefault goes through full validation", func(t *testing.T) { /* ... */ })
    t.Run("Prefault only triggers for nil input", func(t *testing.T) { /* ... */ })
}

// =============================================================================
// Refine tests
// =============================================================================
func Test<Type>_Refine(t *testing.T) { /* ... */ }
func Test<Type>_RefineAny(t *testing.T) { /* ... */ }

// =============================================================================
// Coercion tests (Primitives only)
// =============================================================================
func Test<Type>_Coercion(t *testing.T) { /* ... */ }

// =============================================================================
// Error handling and edge case tests
// =============================================================================
func Test<Type>_ErrorHandling(t *testing.T) { /* ... */ }

// =============================================================================
// OVERWRITE TESTS (Transform/Pipe operations)
// =============================================================================
func Test<Type>_Overwrite(t *testing.T) { /* ... */ }

Read the full file on GitHub · 473 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 473 lines · 4,495 tokens per session scan A ef4557d5b0d4

Subscribe to this mod's changes

schema_test_implementation_guide is a cursor rule published in the GitHub repository kaptinlin/gozod (24 stars, last pushed 1mo ago), licensed MIT. It adds 4,495 tokens to every session, about $0.0225 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.