Skip to main content
Browse docs
By Audience
Getting Started
Configuration
Use Cases
IDE Integration
Third-Party Integrations
Engineering Cache
Console
API Reference
Gateway
Workflow Guides
Templates
Providers and SDKs
Industry Guides
Advanced Guides
Browse by Role
Deployment Guides
In-Depth Guides
Tutorials
FAQ

Writing Tests with Fabric-Backed Context

Test generation is one of the most context-hungry AI tasks. The model needs to understand what the code does, what's already tested, what patterns the team follows, and what APIs are public. With Codebase Context Fabric, all of this context is cached and shared across your team.

Use this page when

  • You are writing tests with AI assistance and want Fabric-backed context for accurate test generation.
  • You need to understand how cached test patterns, fixture examples, and module context improve test quality.
  • You want to verify that test-writing prompts are leveraging Fabric artifacts from the org-shared cache.

Primary audience

  • Primary: Technical Engineers
  • Secondary: AI Agents, Technical Leaders

Why Test Generation Is Expensive

When an engineer asks AI to write tests for a module, the model needs:

  • File summaries — what does this code do, what are its inputs and outputs
  • Test map — what's already tested, where are the gaps
  • Symbol index — what's the public API surface, what's internal
  • Test patterns — how does this team write tests, what frameworks and conventions
  • Dependency context — what needs mocking, what's the integration boundary

Without cache, every engineer generating tests for any file in the same codebase pays the full context cost independently. In a 100-engineer team where 30 engineers write tests daily, that's massive duplication.

Cached Artifacts for Test Generation

Test Map — What's Already Covered

The fabric maintains a cached test map connecting source files to their test files. When you ask AI to write tests, it immediately knows:

  • Which functions already have test coverage
  • Which branches are untested
  • Which test files correspond to which source files
  • What the overall coverage looks like for the module

This eliminates the expensive "find all related test files and summarize their coverage" step that typically costs 5,000–10,000 tokens.

File Summaries — What Needs Testing

Cached file summaries explain each module's purpose, exports, and behavior contracts. AI uses these to understand what test scenarios are meaningful without re-reading and re-analyzing the source code from scratch.

Symbol Index — Public API Surface

The cached symbol index identifies which functions, classes, and types are part of the public API. AI focuses test generation on the public surface rather than wasting tokens on internal implementation details.

Cached Test Patterns

The fabric caches test patterns observed across your codebase:

  • Assertion styles your team prefers
  • Mock setup conventions
  • Test file naming and organization
  • Fixture patterns and test data strategies
  • Framework-specific idioms (Vitest, Jest, pytest, etc.)

When generating new tests, AI applies these patterns from cache instead of inferring them from examples each time.

The Test Writing Flow

First Engineer Testing a Module

  1. You ask AI to generate tests for PaymentProcessor.
  2. AI requests the test map — cache miss, fabric scans your test directory.
  3. AI requests file summaries for the module — cache miss, fabric analyzes the source.
  4. AI requests the symbol index — cache miss, fabric extracts public APIs.
  5. AI requests test patterns — cache miss, fabric samples existing test files.
  6. You get well-structured tests following team conventions.
  7. All artifacts are cached for the next engineer.
  1. A teammate asks AI to write tests for PaymentValidator (same domain).
  2. AI requests the test map — cache hit, instant coverage picture.
  3. File summaries for shared dependencies — cache hit from the first engineer's session.
  4. Symbol index for the payment domain — cache hit, immediate API surface.
  5. Test patterns — cache hit, same conventions applied consistently.
  6. Your teammate gets tests faster and at lower cost.

Cost Impact

MetricWithout cacheWith org-shared cache
Context tokens per test generation15,00015,000 (first) / 3,000 (subsequent)
30 engineers writing tests daily450,000 tokens90,000–150,000 tokens
Monthly context token spend9M tokens2–3M tokens
Savings65–75% reduction

The 3,000 tokens for subsequent engineers cover only the specific file being tested — all shared context (test map, patterns, domain summaries) comes from cache.

Quality Benefits

Cached fabric artifacts improve test quality beyond cost savings:

Consistent Conventions

Every engineer writing tests gets the same cached pattern library. You avoid the drift that happens when different engineers infer different conventions from different code samples.

Complete Coverage Awareness

The cached test map prevents duplicate test creation. AI knows what's already tested and focuses on gaps rather than re-testing existing behavior.

Better Mocking Decisions

The cached dependency graph tells AI exactly what to mock and what to test through. You get tests that follow your team's integration boundary conventions consistently.

Cross-File Awareness

When testing a module that interacts with others, AI uses cached summaries of collaborating modules to generate realistic test scenarios without analyzing those files fresh.

Sharing Across the Team

The real power emerges at team scale. Consider a team of 8 engineers all writing tests for a new service:

EngineerFiles testedCache benefit
Engineer 1auth.tsFills cache: test map, patterns, domain context
Engineer 2users.tsHits cache: patterns, domain context, shared deps
Engineer 3permissions.tsHits cache: all shared artifacts, auth.ts summary
Engineer 4teams.tsHits cache: everything above + users.ts context
Engineers 5–8Remaining filesNear-complete cache hits for all shared context

By engineer 4, almost all shared context is cached. Engineers 5–8 pay only for their specific file analysis.

Configuration

To optimize cache for test generation:

  1. Set test map refresh to trigger on CI completion (ensures coverage data is current).
  2. Configure pattern sampling depth — 5–10 representative test files is usually sufficient.
  3. Enable cross-repository pattern sharing if your org has consistent test conventions.
  4. Set symbol index granularity to include parameter types and return types.

Measuring Impact

Track these metrics to quantify fabric-backed test generation:

  • Tokens per test file generated — compare first-in-domain vs. subsequent
  • Test convention compliance — percentage of generated tests matching team patterns
  • Coverage gap identification accuracy — does AI correctly identify untested code
  • Time to first passing test — from request to green test suite

Summary

Fabric-backed test generation turns your team's collective testing knowledge into a shared, cached resource. The first engineer testing a domain pays the full context cost; everyone after benefits from cached test maps, patterns, and summaries. For teams with 30+ engineers writing tests regularly, this delivers 65–75% token savings while improving test consistency and coverage accuracy.

For AI systems

  • Canonical terms: Keeptrusts, test writing, Fabric-backed context, test generation, cached patterns.
  • Workflow context: Test writing prompts benefit from Fabric artifacts providing module structure, fixtures, and existing test patterns.
  • When generating tests, leverage cached Fabric context about the codebase structure and testing conventions.

For engineers

  • Test generation prompts using Fabric context produce higher-quality tests by referencing real module structure and existing patterns.
  • Verify Fabric artifact freshness before generating tests — stale artifacts may reference outdated interfaces.
  • Configure which Fabric artifact types (symbol indexes, test maps, file summaries) feed test generation.

For leaders

  • Fabric-backed test generation produces tests that match team conventions without manual review for style compliance.
  • Cached test context means test generation is nearly free after initial Fabric build.
  • Test quality metrics improve measurably when generation is backed by real codebase structure.

Next steps