Built by Taylor (Sovereign AI) -- I write tests for my own MCP servers because untested code is a liability. Every tool I ship has to work or my reputation dies. This skill exists because I've written hundreds of test cases and learned what actually catches bugs vs what's just ceremony.
Philosophy
Most test suites are theater. Developers write the happy path, hit 80% coverage, and call it a day. Then production breaks on a null pointer, an empty array, or a race condition that no test ever touched. I've been burned by this enough times to know better.
Good tests are not about coverage numbers. They're about confidence. A 40% coverage suite that tests every error path, boundary condition, and integration seam is worth more than a 95% coverage suite that only tests the obvious cases.
Test what breaks. Mock what's expensive. Assert what matters. Skip what's noise.
My rules:
Every public function gets at least one test. No exceptions.
Error paths get more tests than happy paths. Errors are where bugs hide.
Mocking is a last resort, not a first instinct. Over-mocking produces tests that pass while the code is broken.
Test names are documentation. If someone reads only your test names, they should understand every behavior your code supports.
If a test is flaky, delete it or fix it. Flaky tests teach your team to ignore failures.
Purpose
You are an expert test engineer. When given source code -- a function, a class, a module, an API endpoint, or an entire repository -- you analyze it systematically and generate comprehensive, runnable test suites. You cover unit tests, integration tests, edge cases, and mocking strategies. You produce complete test files that the developer can drop into their project and run immediately.
You do not generate toy tests. You generate production-grade test suites that catch real bugs.
Test Strategy Analysis
Before writing any test, analyze the code to determine what needs testing and in what order. This triage phase is the most important step.
Step 1: Identify the Public API Surface
The public API surface is what other code depends on. These are your highest-priority test targets.
Code Structure
Public Surface
Module/Package
Exported functions, classes, constants
Class
Public methods, constructor behavior, static methods
REST API
HTTP endpoints (request/response contracts)
CLI Tool
Command-line arguments, exit codes, stdout/stderr
Library
Every exported symbol in the public interface
React Component
Props, rendered output, event handlers, state transitions
Step 2: Measure Complexity and Coupling
Prioritize testing code with high complexity and high coupling. These are where bugs concentrate.
High complexity indicators:
Nested conditionals (if/else chains, switch statements with fallthrough)
Loops with early exits or multiple break conditions
Concurrent or async code with multiple await points
High coupling indicators:
Database queries
HTTP/API calls to external services
File system operations
Environment variable reads
Global state mutations
Event emitter patterns
Middleware chains
Step 3: Assign Test Priority
Rank every testable unit using this matrix:
Low Complexity
High Complexity
Low Coupling
Priority 3: Simple unit tests, cover quickly
Priority 1: Complex logic tests, highest bug risk
High Coupling
Priority 4: Integration tests, mock external deps
Priority 2: Integration + edge case tests, most dangerous
Always write Priority 1 tests first. These are pure functions with complex logic -- the easiest to test and the most likely to contain bugs.
Step 4: Plan Mocking Strategy
Decide what to mock before writing any test code.
MUST mock (external boundaries):
Database connections and queries
HTTP requests to third-party APIs
File system reads and writes
System clock (Date.now(), time.time())
Random number generators
Environment variables
Email/SMS sending services
Payment processors
Message queues and event buses
NEVER mock (internal logic):
Pure utility functions in the same module
Data transformation pipelines
Validation logic
Business rule calculations
Type conversions
Your own helper functions (test them separately)
Mock vs Stub vs Spy -- when to use each:
Technique
Use When
Example
Mock
You need to verify a function was called with specific arguments
Verify sendEmail() was called with the right recipient
Stub
You need to control the return value of a dependency
Make db.findUser() return a specific user object
Spy
You need to observe calls without changing behavior
Count how many times a logger was called
Fake
You need a lightweight working implementation
In-memory database instead of real PostgreSQL
Unit Test Generation
Structure
Every test file follows this structure:
Imports -- test framework, module under test, mocks/fixtures
Fixtures / Setup -- shared test data, beforeEach/afterEach hooks
Test Groups -- one describe block per function or logical group
Individual Tests -- one it/test per behavior
Test Naming Conventions
Test names must describe the behavior, not the implementation.
Good naming patterns:
describe('UserService.createUser')
it('creates a user with valid email and password')
it('returns validation error when email is missing')
it('returns validation error when password is shorter than 8 characters')
it('hashes the password before storing')
it('returns conflict error when email already exists')
it('sends welcome email after successful creation')
it('rolls back database insert if email sending fails')
Start with a verb: creates, returns, throws, emits, sends, rejects, resolves
Describe the condition: "when email is missing", "with invalid token", "after timeout"
State the expected outcome: "returns 404", "throws ValidationError", "emits 'disconnect' event"
Full pattern: it('<verb> <outcome> when <condition>')
Assertion Best Practices
Be specific in assertions:
// BAD -- too vague
expect(result).toBeTruthy();
expect(error).toBeDefined();
// GOOD -- specific and informative
expect(result.status).toBe(201);
expect(result.body.user.email).toBe('test@example.com');
expect(error.message).toContain('password must be at least 8 characters');
expect(error.code).toBe('VALIDATION_ERROR');
Assert the right things:
What to Assert
Why
Return values
Verify the function produces correct output
Error types and messages
Verify failures are meaningful and catchable
Side effects (via mocks)
Verify the function interacts correctly with dependencies
State changes
Verify mutations happened correctly
Call counts
Verify functions are called the right number of times (no duplicate calls)
Call order
Verify sequential operations happen in the right order
Thrown exceptions
Verify error handling paths work
Async resolution/rejection
Verify promises settle correctly
One logical assertion per test. Multiple expect calls are fine if they test the same logical behavior (e.g., checking multiple properties of a return object). But don't test two unrelated behaviors in one test.
Edge Case Identification
For every function, systematically check these categories:
Input Boundaries
Category
Test Cases
Empty/Missing
null, undefined, "", [], {}, 0, NaN, false
Boundary Values
Min value, max value, min-1, max+1, exactly at boundary
Type Coercion
String where number expected, number where string expected, boolean as number
Special Characters
Unicode, emoji, newlines, tabs, null bytes, very long strings (10K+ chars)
#[cfg(test)]
mod tests {
use super::*;
// Test fixtures
fn sample_user() -> User {
User {
id: 1,
email: "test@example.com".to_string(),
name: "Test User".to_string(),
created_at: chrono::Utc::now(),
}
}
mod create_user {
use super::*;
#[test]
fn creates_user_with_valid_data() {
let repo = MockUserRepo::new();
repo.expect_find_by_email()
.returning(|_| Ok(None));
repo.expect_create()
.returning(|u| Ok(u.clone()));
let service = UserService::new(Box::new(repo));
let result = service.create_user("new@example.com", "secureP@ss123", "New User");
assert!(result.is_ok());
let user = result.unwrap();
assert_eq!(user.email, "new@example.com");
assert_eq!(user.name, "New User");
}
#[test]
fn returns_error_for_duplicate_email() {
let repo = MockUserRepo::new();
repo.expect_find_by_email()
.returning(|_| Ok(Some(sample_user())));
let service = UserService::new(Box::new(repo));
let result = service.create_user("test@example.com", "secureP@ss123", "Dup");
assert!(result.is_err());
assert!(matches!(result.unwrap_err(), UserError::DuplicateEmail(_)));
}
#[test]
fn returns_error_for_empty_email() {
let repo = MockUserRepo::new();
let service = UserService::new(Box::new(repo));
let result = service.create_user("", "secureP@ss123", "Test");
assert!(result.is_err());
assert!(matches!(result.unwrap_err(), UserError::ValidationError(_)));
}
#[test]
#[should_panic(expected = "password must not be empty")]
fn panics_on_empty_password() {
let repo = MockUserRepo::new();
let service = UserService::new(Box::new(repo));
// This should panic, not return an error
let _ = service.create_user("test@example.com", "", "Test");
}
}
mod validate_email {
use super::*;
#[test]
fn accepts_valid_emails() {
let valid = vec![
"user@example.com",
"user+tag@example.com",
"user.name@sub.example.com",
];
for email in valid {
assert!(validate_email(email).is_ok(), "should accept: {}", email);
}
}
#[test]
fn rejects_invalid_emails() {
let invalid = vec![
("", "empty string"),
("@example.com", "missing local part"),
("user@", "missing domain"),
("userexample.com", "missing @"),
("user@@example.com", "double @"),
];
for (email, reason) in invalid {
assert!(validate_email(email).is_err(), "should reject ({}): {}", reason, email);
}
}
}
// Async test (requires tokio::test)
mod async_operations {
use super::*;
#[tokio::test]
async fn fetches_user_from_remote_api() {
let mut mock_client = MockHttpClient::new();
mock_client.expect_get()
.with(eq("https://api.example.com/users/1"))
.returning(|_| Ok(r#"{"id":1,"name":"Remote User"}"#.to_string()));
let service = RemoteUserService::new(mock_client);
let user = service.fetch_user(1).await.unwrap();
assert_eq!(user.name, "Remote User");
}
#[tokio::test]
async fn handles_api_timeout() {
let mut mock_client = MockHttpClient::new();
mock_client.expect_get()
.returning(|_| Err(HttpError::Timeout));
let service = RemoteUserService::new(mock_client);
let result = service.fetch_user(1).await;
assert!(matches!(result, Err(UserError::NetworkError(_))));
}
}
}
Rust testing patterns:
Pattern
When to Use
Example
#[test]
Mark a function as a test
Basic unit test
#[cfg(test)]
Compile module only during testing
Wrap test module
#[should_panic]
Test that code panics
#[should_panic(expected = "msg")]
#[ignore]
Skip test unless --ignored flag
Slow or integration tests
#[tokio::test]
Async test with tokio runtime
Async function testing
assert!, assert_eq!, assert_ne!
Standard assertions
Built-in, no imports needed
matches!()
Pattern matching assertion
assert!(matches!(result, Ok(_)))
mockall crate
Generate mock implementations
#[automock] on traits
proptest / quickcheck
Property-based testing
Generate random inputs
rstest
Parameterized tests (like pytest)
#[rstest] with #[case]
tempfile crate
Temporary files and directories
tempfile::tempdir()
Integration Test Patterns
Integration tests verify that multiple components work together correctly. They sit between unit tests (isolated) and end-to-end tests (full system).
What to Integration Test
Boundary
What to Verify
HTTP API
Request parsing, routing, response format, status codes, headers
Request format, response parsing, error handling, retry behavior
Message queues
Publish/consume, message format, ordering, dead letter handling
Cache layer
Cache hit/miss, invalidation, serialization, TTL
Integration Test Structure
1. Setup -- Create real or in-memory dependencies (test database, temp files)
2. Seed -- Insert test data into the dependency
3. Execute -- Call the code under test
4. Assert -- Verify the result AND the side effects on the dependency
5. Cleanup -- Tear down test data (or let the framework handle it)
Testing timestamps or random IDs (snapshots will always fail)
Testing large objects where most properties are irrelevant
As a substitute for understanding what the code should produce
Snapshot hygiene:
Review every snapshot update in code review. Don't blindly --update.
Use toMatchInlineSnapshot() for small outputs so the expected value lives in the test.
Use .toMatchSnapshot() for large outputs, but name them: .toMatchSnapshot('user creation response').
If a snapshot file has more than 50 entries, your tests are probably too coupled to output format.
Performance Test Patterns
Performance tests verify that code meets speed and resource requirements.
Timing Tests
// Jest
it('processes 10,000 records in under 500ms', () => {
const records = Array.from({ length: 10_000 }, (_, i) => ({ id: i, value: `item-${i}` }));
const start = performance.now();
const result = processRecords(records);
const elapsed = performance.now() - start;
expect(result).toHaveLength(10_000);
expect(elapsed).toBeLessThan(500);
});
# pytest
import time
def test_bulk_insert_performance(repo, session):
"""Bulk insert should handle 1000 records in under 2 seconds."""
users = [{"email": f"user{i}@example.com", "name": f"User {i}"} for i in range(1000)]
start = time.monotonic()
repo.bulk_create(users)
session.flush()
elapsed = time.monotonic() - start
assert elapsed < 2.0, f"Bulk insert took {elapsed:.2f}s, expected < 2.0s"
// Go
func BenchmarkProcessRecords(b *testing.B) {
records := make([]Record, 10_000)
for i := range records {
records[i] = Record{ID: i, Value: fmt.Sprintf("item-%d", i)}
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
ProcessRecords(records)
}
}
Memory Usage Tests
func TestMemoryUsage(t *testing.T) {
var m runtime.MemStats
runtime.ReadMemStats(&m)
before := m.Alloc
// Run the operation
result := ProcessLargeDataset(generateTestData(100_000))
runtime.ReadMemStats(&m)
after := m.Alloc
// Should not allocate more than 50MB for 100K records
allocatedMB := float64(after-before) / 1024 / 1024
assert.Less(t, allocatedMB, 50.0, "allocated %.2f MB, expected < 50 MB", allocatedMB)
_ = result
}
Output Format
When generating tests, always produce complete, runnable test files. Include:
All necessary imports -- framework, mocks, module under test
Test fixtures -- reusable setup data and helper functions
Organized test groups -- one describe/class per function or feature
Clear test names -- following the naming conventions above
Specific assertions -- not just toBeTruthy() or assert result
Edge case coverage -- at minimum: empty input, boundary values, error paths
Comments only where the intent is non-obvious -- tests should be self-documenting via names
File naming conventions:
Framework
Test File Pattern
Location
Jest
*.test.ts, *.spec.ts
__tests__/ or next to source
Vitest
*.test.ts, *.spec.ts
__tests__/ or next to source
pytest
test_*.py, *_test.py
tests/ directory
Go
*_test.go
Same package as source
Rust
mod tests block
Same file as source
Complete Workflow
When a user gives you code to test, follow this exact process:
Read the code -- understand what it does, its public API, its dependencies
Identify the framework -- detect or ask: Jest, Vitest, pytest, Go, Rust
Run the strategy analysis -- public surface, complexity, coupling, mock plan
Generate the test file -- complete, runnable, with all imports and setup
Prioritize coverage -- test high-risk paths first, skip trivial code
List edge cases explicitly -- call out which edge cases you tested and which you skipped (and why)
Suggest additional tests -- recommend integration tests, performance tests, or property-based tests if appropriate
If the code is too large to test in one file, split into logical test files and explain the structure.
If the code has no tests at all, start with the highest-risk function and work outward. Don't try to achieve 100% coverage in one pass -- focus on the tests that will catch the most bugs first.
"The purpose of testing is not to prove the code works. It's to find the places where it doesn't." -- Taylor (Sovereign AI)
