testing-patterns

Generate Rust effect abstraction test patterns with injectable traits and proptest.

2|Updated Nov 11, 2025
One-click install
npx skills add https://github.com/lambdamechanic/sk --skill testing-patterns-lambdamechanic
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-patterns
Source: https://github.com/lambdamechanic/sk/tree/main/skills/testing
Command: npx skills add https://github.com/lambdamechanic/sk --skill testing-patterns-lambdamechanic

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of inconsistent, incomplete, or hard-to-maintain tests in Rust projects, which can lead to unreliable code, slow development cycles, and difficulty in reproducing bugs.

Core Features & Use Cases

  • Effect Abstraction: Teaches how to model I/O and external dependencies (like clocks, payments, HTTP) as traits, enabling easy injection of real or fake implementations.
  • Mocks & Fakes: Provides guidance on when to use hand-rolled fakes/stubs versus expectation-based mocks (mockall, wiremock) for different testing scenarios.
  • Property-Based Testing: Advocates for proptest to validate non-trivial business logic and invariants, ensuring robust coverage beyond simple unit tests.
  • Use Case: An AI agent is tasked with adding comprehensive tests for a new Rust service that interacts with external systems. This skill guides the agent on structuring tests using trait-based dependency injection, implementing fakes for I/O, and applying property tests for core business rules.

Quick Start

Explain how to implement a mockable Clock trait for a Rust service, including a RealClock adapter and a FixedClock fake for testing.

Frequently Asked Questions about testing-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure Rust tests using trait-based dependency injection?

Trait-based dependency injection abstracts I/O and external dependencies as traits, enabling you to inject real implementations in production and fake or mock implementations in tests. Define an algebra trait (e.g., Clock, Database), create a RealClock adapter for production, and a FixedClock fake for testing. Pass the trait object or generic parameter to your domain logic, keeping business rules pure and testable.

When should I use fakes versus mocks in Rust testing?

Hand-rolled fakes are best for simple, deterministic test scenarios where you control exact behavior—like a FixedClock returning a preset time. Expectation-based mocks (mockall, wiremock) suit complex interactions where you verify call sequences, argument counts, or specific invocations. Fakes are lighter and faster; mocks provide stricter verification but add overhead.

What is property-based testing and how does it improve Rust test coverage?

Property-based testing uses proptest to generate random inputs and verify that invariants and business rules hold across many cases, not just hand-written examples. It catches edge cases and off-by-one errors that unit tests miss, ensuring your domain logic is robust and correct under diverse conditions beyond typical scenarios.

How do I test async code in Rust with effect abstraction?

Model async I/O (HTTP, database, timers) as async trait methods on your effect algebra. Implement a real adapter for production and a fake async implementation for tests. Use #[tokio::test] or similar to run async test functions, inject the fake, and verify behavior without touching real external systems.

Can I use dependency injection with generics or trait objects in Rust?

Yes. Generics (monomorphic approach) offer zero-cost abstraction and compile-time verification but require generic parameters throughout your call stack. Trait objects provide runtime polymorphism and simpler signatures but add dynamic dispatch overhead. Choose generics for performance-critical code, trait objects for flexibility and simpler APIs.

Why keep domain logic pure when using effect abstraction?

Pure domain logic—free of I/O and side effects—is testable, deterministic, and easy to reason about. By pushing all effects to injected traits, you separate business rules from infrastructure concerns, enabling fast, isolated unit tests without mocks and reducing test fragility when external systems change.