composable-rust-testing

Write unit and integration tests for Composable Rust applications using TestStore and FixedClock.

Updated Nov 5, 2025
One-click install
npx skills add https://github.com/jonathanbelolo/composable-rust --skill composable-rust-testing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: composable-rust-testing
Source: https://github.com/jonathanbelolo/composable-rust/tree/main/.claude/skills/composable-rust-testing
Command: npx skills add https://github.com/jonathanbelolo/composable-rust --skill composable-rust-testing

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides expert testing guidance for Composable Rust applications, helping developers write fast unit tests for reducers, set up reliable integration tests with real dependencies, and leverage a rich set of test utilities such as TestStore, FixedClock, mocks, and property-based testing patterns.

Core Features & Use Cases

  • Unit testing reducers: Pure, deterministic tests that exercise state transitions without I/O, using patterns like the ReducerTest builder and in-file #[cfg(test)] modules.
  • Integration testing with real dependencies: End-to-end validation using real components (e.g., PostgreSQL, message buses) via testcontainers, migrations, and realistic environments.
  • Test utilities & patterns: Guided use of TestStore, FixedClock, mocks, and saga-wait patterns to deterministically drive async work and verify outcomes.
  • Property-based testing & async patterns: Property tests with proptest to uncover edge cases; asynchronous tests with #[tokio::test].

Quick Start

Use the composable-rust-testing skill to write unit and integration tests by leveraging ReducerTest, TestStore, and FixedClock in your Rust project. For example, create a test environment, initialize a reducer and state, invoke reduce, and assert on resulting state and effects.

Frequently Asked Questions about composable-rust-testing

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

FAQPage Schema
How do I write unit tests for Rust reducers without I/O side effects?

Write unit tests for Rust reducers by using a ReducerTest builder within in-file #[cfg(test)] modules to exercise pure state transitions deterministically. This approach isolates reducer logic from I/O dependencies, enabling fast and reliable state transition verification.

What's the best way to set up integration tests for Rust apps with real dependencies like PostgreSQL?

Set up Rust integration tests with real dependencies by spinning up real components like PostgreSQL and message buses via testcontainers, running migrations, and validating end-to-end behavior in a realistic environment. This ensures reliable integration testing without manual infrastructure management.

How does property-based testing with proptest work for uncovering edge cases in Rust applications?

Property-based testing with proptest in Rust applications works by automatically generating varied test inputs to uncover edge cases in state transitions and reducer logic. It validates that defined properties hold across a wide range of inputs, revealing edge cases that manual test cases might miss.

Can I use TestStore and FixedClock to deterministically test async workflows in Rust?

Yes, you can use TestStore and FixedClock to deterministically drive and verify async workflows in Rust. These test utilities, combined with saga-wait patterns and mocks, allow you to control time and state, ensuring deterministic outcomes in asynchronous tests.

How do I organize tests across multiple crates in a Composable Rust project?

Organize tests across multiple crates in a Composable Rust project by enforcing best practices for test organization, separating fast unit tests for reducers from integration tests, and leveraging shared test utilities like TestStore and mocks to maintain consistency.

When should I use testcontainers instead of mocks for Rust integration testing?

Use testcontainers instead of mocks for Rust integration testing when you need end-to-end validation with real dependencies like PostgreSQL and message buses. Mocks are better for isolating specific components, while testcontainers provide realistic environments for comprehensive integration tests.