Skip to content

Add an #[explicit_test_case] feature.#144

Open
DRMacIver wants to merge 5 commits intomainfrom
DRMacIver/explicit-test-case
Open

Add an #[explicit_test_case] feature.#144
DRMacIver wants to merge 5 commits intomainfrom
DRMacIver/explicit-test-case

Conversation

@DRMacIver
Copy link
Copy Markdown
Member

Depends on #143. Review that one first.

This mirrors Hypothesis's example decorator. It lets you explicitly
provide a test case as a set of inputs to your test function.

Here's it in action. Consider the following:

const BAD_VALUE: u32 = 124352450;

#[hegel::test]
#[hegel::explicit_test_case(
    x = BAD_VALUE
)]
fn my_test(tc: hegel::TestCase){
    let x = tc.draw(hegel::generators::integers::<u32>());
    assert!(x != BAD_VALUE);
}

If you run this you will see:

let x = BAD_VALUE; // = 124352450

thread 'my_test' (15608116) panicked at examples/explicit_test_case.rs:9:5:
assertion failed: x != BAD_VALUE

It will not work in all cases. Currently in some of those cases it will likely produce very bad error messages. I've tried to do my best to think of the common cases for this and provide good error messages there, ideally at compile time, but there are 100% going to be some missing ones that we can improve over time.

DRMacIver and others added 5 commits March 27, 2026 10:22
This introduces draw_named as the primitive for when we are actually
printing, which provides much nicer output for values.

It then makes the hegel::test macro automatically rewrite draw()
to draw_named where it is safe to do so.
- Remove explicit 'a lifetime in is_tc_draw_binding (clippy::needless_lifetimes)
- Move NOTE text outside ```no_run code fence in draw() doc comment
- Allow clippy::let_and_return in closure test (needed for macro rewrite testing)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This mirrors Hypothesis's example decorator. It lets you explicitly
provide a test case as a set of inputs to your test function.

It will not work in all cases. Currently in some of those cases it
will likely produce very bad error messages. I've tried to do my
best to think of the common cases for this, but there are 100% going
to be some missing ones that we can improve over time.
@DRMacIver DRMacIver marked this pull request as ready for review March 27, 2026 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant