rstest
rstest is a Rust testing framework that uses procedural macros to simplify writing fixture-based and parametrized tests. It reduces boilerplate by allowing you to inject test dependencies as function arguments and automatically generate multiple test cases from parameter lists.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | la10736/rstest |
| Owner | la10736 |
| Primary language | Rust |
| License | Apache-2.0 — OSI-approved |
| Stars | 1.6k |
| Forks | 72 |
| Open issues | 73 |
| Latest release | v0.26.1 (2025-07-27) |
| Last updated | 2026-03-26 |
| Source | https://github.com/la10736/rstest |
What rstest is
rstest provides procedural macro attributes (#[rstest], #[fixture], #[case]) to enable fixture injection, parametrized test generation (including matrix tests), async test support with optional await-removal, timeout control, and file-path-based test generation via glob patterns. It requires explicit or implicit async runtime declaration and supports feature-gated test cases.
Get the rstest source
Clone the repository and explore it locally.
git clone https://github.com/la10736/rstest.gitcd rstest# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Async tests require explicit runtime declaration (e.g., #[tokio::test]); rstest does not provide or assume a runtime.
- Fixture scope and initialization order should be documented; shared fixtures using #[once] are evaluated once per test session.
- Parametrize attributes (#[case], #[values], #[files]) are resolved at compile time; runtime parameter injection is not supported.
- Feature-gated test cases use #[cfg_attr(feature = "...", case(...))] syntax; ensure feature flags are coordinated across dev and test targets.
- Timeout feature requires the async-timeout feature flag (enabled by default); verify it is compatible with your async runtime.
When to avoid it — and what to weigh
- Performance-critical test harness — Procedural macro expansion adds compile-time overhead. If test binary size or build time is tightly constrained, the macro-generated code may be problematic compared to hand-written tests.
- Minimal-dependency projects — rstest adds a dev dependency with macro expansion complexity. Projects targeting embedded or no_std environments should evaluate if the macro footprint is acceptable.
- Projects requiring stable Rust features only — rstest relies on procedural macros, which have historically been less stable than core language features. Teams strictly on stable Rust should confirm feature compatibility before adoption.
- Simple, deterministic test suites without dynamic cases — If all tests are straightforward and case generation is not needed, adding rstest may introduce unnecessary complexity. Standard Rust #[test] or simpler frameworks may be more appropriate.
License & commercial use
Licensed under Apache License 2.0 (Apache-2.0), a permissive open-source license. The README also references MIT licensing in badges, but the primary license is Apache-2.0. Both are OSI-approved and allow commercial use with minimal restrictions.
Apache-2.0 is a permissive OSI license that permits commercial use in proprietary projects without royalties. Attribution is required. No source disclosure of your own code is mandated. Review Apache-2.0 terms for liability disclaimers and patent clauses relevant to your use case.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Strong |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Good |
| Assessment confidence | High |
rstest is a compile-time macro framework with no runtime or network dependencies. Procedural macros execute during compilation; review the macro source if your threat model includes untrusted build environments. File-path globbing (#[files]) operates at compile time, so path injection is not a runtime concern. No known security advisories in the data provided.
Alternatives to consider
Rust built-in #[test] + loops
Standard Rust testing without external dependencies. Simpler for basic tests, but requires manual loop/case generation and lacks fixture ergonomics.
proptest
Property-based testing framework generating random inputs. Complements rstest for exhaustive property exploration; use both together or choose proptest if randomized input coverage is the priority.
criterion.rs
Specialized for benchmarking and performance testing. Different use case (latency measurement) but can coexist with rstest for mixed unit + benchmark suites.
Build on rstest with DEV.co software developers
rstest's macro-driven approach reduces boilerplate and improves test maintainability. Explore integration with your project or contact our team to evaluate its fit for your testing strategy.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
rstest FAQ
Does rstest require a specific async runtime?
Can I use rstest with stable Rust?
What is the compile-time overhead?
Can I share parametrization across multiple test functions?
Custom software development services
DEV.co helps companies turn open-source tools like rstest into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source testing stack.
Ready to streamline your Rust test suite?
rstest's macro-driven approach reduces boilerplate and improves test maintainability. Explore integration with your project or contact our team to evaluate its fit for your testing strategy.