-
Notifications
You must be signed in to change notification settings - Fork 34
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
Fix handling of test_case with custom name #30
Conversation
77e6c69
to
b230d03
Compare
5a850f3
to
e9b6b35
Compare
@d-e-s-o would you mind having a look at this? |
Sorry for the delay. Seems like a good set of simplifications. Can you please remove the various formatting changes, though? Regarding the second to last commit, can we remove |
Hm, but that isn't what is being done, or am I misreading something? |
Or for the actual code reuse one of my other rustfmt files. But please keep toml. |
Add a job to check formatting in Github Actions. Copied from https://github.com/d-e-s-o/apca/blob/main/rustfmt.toml.
This function doesn't serve much of a purpose now. In the next commit, we need to change how we handle its inputs; better to just inline it to reduce churn.
Parsing `test_case::test_case(-2, -4; "my test name")` as `AttributeArgs` would fail because a semicolon is illegal in `AttributeArgs`. There's nothing of value being done after this parsing, so better to replace it with a simple fallback if the wrapper attribute is absent.
Add minimal taplo config that retains current formatting.
This is otherwise not referenced. Remove the need to add a dependency on `tracing` from the README.
Done.
Done.
Correct, that is not what's being done. That's a separate commentary. Changing that would break existing users, so I didn't do it here. |
b28dfa4
to
f0182d4
Compare
Sorry, running behind on this request. Will try to merge this by the end of the week. |
I added CHANGELOG entries and merged the changes with a few minor modifications. Thanks for taking the time to contribute to the project! |
See individual commits.
Still missing is guidance on how to write
#[test_case(...)]
tests with multiple cases. For exampledoesn't work.
I think the approach of wrapping other test macros such as
tokio::test
andtest_case::test_case
in thetest_log::test
macro ends up being inflexible for such cases and it's probably better to abandon it in favor ofparsing other attributes on the test function and inserting
#[test]
only if nothing else has already done it. Thiswould mean that ordering of attributes would start to matter but this is already the case when
test_case::test_case
iscomposed with
tokio::test
;test_case
has to come first or else compilation fails with "functions used as tests cannot have any arguments".