-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
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_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 |
Given frondeus/test-case#143 (comment), I think it is ok for |
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.
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.
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.
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.
`#[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.
`#[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.
`#[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.
Closes #51.