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

Add a setting to remove part of the module name #601

Open
nyurik opened this issue Sep 19, 2024 · 1 comment
Open

Add a setting to remove part of the module name #601

nyurik opened this issue Sep 19, 2024 · 1 comment

Comments

@nyurik
Copy link

nyurik commented Sep 19, 2024

In some cases, especially when the snapshot files reside in a sub-directory next to the test files, snapshot filenames become increasingly hard to manage. I would like to propose a setting to remove some beginning parts of the module name with a setting.

Example setup

My project crate myproj contains a proc macro in the crate myproj-macros. When testing proc-macros, it is the easiest to keep the tests in a sub-directory, e.g. ./myproj-macros/src/tests instead of being in parallel to ./myproj-macros/src because procmacro crates cannot have any public exported functions (this way these are unit, not integration tests, and the entire test submodule is behind #[cfg(test)]).

If my tests use insta, the snapshot dir is created next to them in the ./myproj-macros/src/tests/snapshots. The filename then becomes huge (assuming i am using named tests)

./myproj-macros/src/tests/snapshots/myproj_macros__tests__testfilename_testname.snap

A more readable name would be testfilename__testname.snap

Suggestion

The test name is generated with module_path!() -- which in my case is myproj_macros::tests::testfilename. I think it would be great if we could remove some prefix from it. Some approaches:

  • give a hardcoded string myproj_macros::tests -- that string must exits in the module name and end in :: (fail otherwise)
  • give a number of levels to remove, 2 in this case
  • number of characters to remove (not a good idea, i know)
@max-sixty
Copy link
Sponsor Collaborator

max-sixty commented Sep 19, 2024

Yes, is this the same as #377; do we need more flexibility or is the proposed default there of no repetition sufficient?

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

No branches or pull requests

2 participants