DEV.co
Open-Source Testing · la10736

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.

Source: GitHub — github.com/la10736/rstest
1.6k
GitHub stars
72
Forks
Rust
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryla10736/rstest
Ownerla10736
Primary languageRust
LicenseApache-2.0 — OSI-approved
Stars1.6k
Forks72
Open issues73
Latest releasev0.26.1 (2025-07-27)
Last updated2026-03-26
Sourcehttps://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.

Quickstart

Get the rstest source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/la10736/rstest.gitcd rstest# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Property-based and parametrized unit testing

Ideal for projects requiring extensive coverage of input combinations. The #[case] and #[values] attributes generate independent test cases automatically, reducing repetitive test code while maintaining clarity.

Async Rust applications with complex fixtures

Excellent for testing async Tokio, async-std, or other async runtime code. The #[future] and #[awt] attributes simplify handling of async fixtures and test inputs, making async test code more readable than manual .await chaining.

Integration and file-driven tests

Strong fit for tests that iterate over multiple input files or configurations. The #[files(...)] attribute with glob patterns compiles file discovery at build time, enabling scalable test generation for file processing pipelines.

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.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

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.

Software development agency

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.co

Related 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?
No. rstest is runtime-agnostic. You must declare the runtime explicitly (e.g., #[tokio::test], #[async_std::test]) on the test function. rstest provides the fixture and parametrization macros; the runtime is your responsibility.
Can I use rstest with stable Rust?
Unknown. Procedural macros have historically required nightly in early versions but are now stable. The data does not explicitly confirm minimum MSRV or stable compatibility; check the Cargo.toml or docs.rs for MSRV.
What is the compile-time overhead?
Unknown. Macro expansion adds compilation time, but no benchmarks are provided in the data. For large parametrized test suites, rebuild times may be noticeable; evaluate on your codebase.
Can I share parametrization across multiple test functions?
Yes, via the rstest_reuse crate, which provides #[template] and #[apply] attributes to define reusable parametrization templates.

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.