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

Leave annotated item outside test module #77

Closed
nakedible opened this issue Dec 27, 2021 · 2 comments · Fixed by #88
Closed

Leave annotated item outside test module #77

nakedible opened this issue Dec 27, 2021 · 2 comments · Fixed by #88
Labels
next release Issues that are meant to release with next minor/major release
Milestone

Comments

@nakedible
Copy link

I'm not sure if I'm the only one asking for this, but this feels like a no brainer, so it's kind of curious...

I want to use #[test_case] annotations on functions that are not test functions but the actual functions that implement things. They might be a part of the public API, or just used by many other functions in the same file. This would be similar to writing a "doc test", but a doc test is necessarily 3 lines and quite verbose compared to just a test_case annotation. Additionally, doc tests are not part of the normal unit test frameworks, but instead handled with a special binary, which causes all sorts of annoyance.

Currently, just adding the annotation causes there to be a module added with the function name, and the function to be moved inside that module, and then followed by all the generated test case functions. Instead, I would want the module to be named test_<ident>, the generated test cases placed inside that and the function to be left exactly as is. To be honest, that's how I assumed this to work.

This would probably need to be a flag, or a separate macro, since I guess all the current users assume that the test case function is purely for testing.

@luke-biel
Copy link
Collaborator

Hmm, this seems like a valid use case of the crate and no, I don't recall any talks about this feature.

I can say that placing fn within created module is a leftover from very early version of this lib and I can't even recall if reasoning is still valid. I'd have to just try moving function upwards. I also just checked that #[test] is allowed outside of #[cfg(test)] - i guess always writting tests in same manner makes you have some weird assumptions.

As for flag/separate macro - we're closing in on 2.0, so breaking changes are allowed and it shouldn't break anything too hard. One case would be if users would write something like:

#[test_case(...)]
fn abcdef() {}

fn abcdef() {}

since it's not clashing on 1.0, but would on 2.0.

Sooo... can't promise it ships with next major release, but I really like this and I'm gonna try to drop it in.

@luke-biel luke-biel mentioned this issue Jan 2, 2022
7 tasks
@luke-biel luke-biel added this to the 2.0.0 milestone Jan 2, 2022
@nakedible
Copy link
Author

Awesome! Much love ❤️

@luke-biel luke-biel added the next release Issues that are meant to release with next minor/major release label Jan 28, 2022
luke-biel added a commit that referenced this issue Feb 13, 2022
* handle returning `Result` from test_case when `=>` is absent #50 
* leave tested item in scope it was defined in #77
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next release Issues that are meant to release with next minor/major release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants