Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: fix duplicated test runs from test_case and stuck::test #53

Merged
merged 1 commit into from
Apr 19, 2024

Conversation

kezhuw
Copy link
Owner

@kezhuw kezhuw commented Apr 17, 2024

Closes #51.

@kezhuw
Copy link
Owner Author

kezhuw commented Apr 18, 2024

This bases on the general solutions I posted in frondeus/test-case#143. But after rethinking the whole things from ground. I think following rule should work even better.

Don't generate any form of #[test], let user to do it instead.

#[test_case("noop")]
#[tokio::test]
#[test_log::test]
#[test]
async fn test_method(name: &str) {
    // ...
}

This way the above code should work intuitively. Test proc macros should only transform or decorate test method.

Sadly, it is apparently a breaking change. Even worse, doing this in major version probably will lose tests silently. Other approaches are probably not general enough(d-e-s-o/test-log@5281a23) or need cooperation among macros(frondeus/test-case#143).

Let the compiler to merge/deduplicate #[test] is also an approach. Seems that test is a compiler builtin macro. Not sure it is worth, as I think it is a mistake to generate #[test] as it is not composable and cooperative.

@kezhuw
Copy link
Owner Author

kezhuw commented Apr 19, 2024

Given frondeus/test-case#143 (comment), I think it is ok for #[stuck::test] to append #[::core::prelude::v1::test] in case of it does not exist.

@kezhuw kezhuw merged commit 1ed9783 into master Apr 19, 2024
12 checks passed
kezhuw added a commit to kezhuw/rstest that referenced this pull request Jan 16, 2025
This way test macros following `#[rstest]` can decide whether or not to
generate test macro to avoid duplicate test runs.

It is an attempt to improve capabilities among test macros. Currently,
following test from [googletest](https://github.com/google/googletest-rust/blob/21f2948684847922a416252b8118e3eada8e29d6/integration_tests/src/google_test_with_rstest.rs#L52-L57)(`main` branch at 2025-01-16) will run twice.

```rust
#[rstest]
#[case(1)]
#[gtest]
fn paramterised_test_should_work_with_rstest_first(#[case] value: u32) -> Result<()> {
    verify_that!(value, eq(value))
}
```

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
kezhuw added a commit to kezhuw/rstest that referenced this pull request Jan 16, 2025
This way test macros following `#[rstest]` can decide whether or not to
generate test macro to avoid duplicate test runs.

It is an attempt to improve capabilities among test macros. Currently,
following test from [googletest](https://github.com/google/googletest-rust/blob/21f2948684847922a416252b8118e3eada8e29d6/integration_tests/src/google_test_with_rstest.rs#L52-L57)(`main` branch at 2025-01-16) will run twice.

```rust
#[rstest]
#[case(1)]
#[gtest]
fn paramterised_test_should_work_with_rstest_first(#[case] value: u32) -> Result<()> {
    verify_that!(value, eq(value))
}
```

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
kezhuw added a commit to kezhuw/rstest that referenced this pull request Jan 17, 2025
This way test macros following `#[rstest]` can decide whether or not to
generate test macro to avoid duplicate test runs.

It is an attempt to improve capabilities among test macros. Currently,
following test from [googletest](https://github.com/google/googletest-rust/blob/21f2948684847922a416252b8118e3eada8e29d6/integration_tests/src/google_test_with_rstest.rs#L52-L57)(`main` branch at 2025-01-16) will run twice.

```rust
#[rstest]
#[case(1)]
#[gtest]
fn paramterised_test_should_work_with_rstest_first(#[case] value: u32) -> Result<()> {
    verify_that!(value, eq(value))
}
```

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
la10736 pushed a commit to la10736/rstest that referenced this pull request Jan 17, 2025
This way test macros following `#[rstest]` can decide whether or not to
generate test macro to avoid duplicate test runs.

It is an attempt to improve capabilities among test macros. Currently,
following test from [googletest](https://github.com/google/googletest-rust/blob/21f2948684847922a416252b8118e3eada8e29d6/integration_tests/src/google_test_with_rstest.rs#L52-L57)(`main` branch at 2025-01-16) will run twice.

```rust
#[rstest]
#[case(1)]
#[gtest]
fn paramterised_test_should_work_with_rstest_first(#[case] value: u32) -> Result<()> {
    verify_that!(value, eq(value))
}
```

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
kezhuw added a commit to kezhuw/googletest-rust that referenced this pull request Jan 20, 2025
`#[gtest]` will benefit from la10736/rstest#291, we could also benefit
other test macros.

It is an attempt to improve capabilities among test macros to avoid
duplicated test runs which is rare to be aware of.

The rationale is simple: procedure of attribute macro see only
attributes following it. Macros next to processing macro will not see
generated macro if it is generated in-place. So, instead of generating
test macro in-place, appending generated test macro will let macros next
to processing macro have chance to react, for example, not generate test
macro if there is already one.

We could deprecate `#[googletest::test]` oneday after rust-lang/rust#82419
released.

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143,
la10736/rstest#291, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
kezhuw added a commit to kezhuw/googletest-rust that referenced this pull request Jan 20, 2025
`#[gtest]` will benefit from la10736/rstest#291, we could also benefit
other test macros.

It is an attempt to improve capabilities among test macros to avoid
duplicated test runs which is rare to be aware of.

The rationale is simple: procedure of attribute macro see only
attributes following it. Macros next to processing macro will not see
generated macro if it is generated in-place. So, instead of generating
test macro in-place, appending generated test macro will let macros next
to processing macro have chance to react, for example, not generate test
macro if there is already one.

We could deprecate `#[googletest::test]` oneday after la10736/rstest#291
released.

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143,
la10736/rstest#291, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
kezhuw added a commit to kezhuw/googletest-rust that referenced this pull request Jan 20, 2025
`#[gtest]` will benefit from la10736/rstest#291, we could also benefit
other test macros.

This is an attempt to improve capabilities among test macros to avoid
duplicated test runs which is rare to be aware of.

The rationale is simple: procedure of attribute macro see only
attributes following it. Macros next to processing macro will not see
generated macro if it is generated in-place. So, instead of generating
test macro in-place, appending generated test macro will let macros next
to processing macro have chance to react, for example, not generate test
macro if there is already one.

We could deprecate `#[googletest::test]` oneday after la10736/rstest#291
released.

See: tokio-rs/tokio#6497, d-e-s-o/test-log#46, frondeus/test-case#143,
la10736/rstest#291, kezhuw/stuck#53.
Refs: rust-lang/rust#67839, rust-lang/rust#82419.
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.

Test macro compatibility with test-case and possible others
1 participant