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

Generate mutations in header files (hpp) but not in tests (cpp) #1076

Open
correaa opened this issue Dec 19, 2024 · 3 comments
Open

Generate mutations in header files (hpp) but not in tests (cpp) #1076

correaa opened this issue Dec 19, 2024 · 3 comments

Comments

@correaa
Copy link

correaa commented Dec 19, 2024

I have a header-only library that is a bunch of .hpp files.
The tests are .cpp files of course.

When mull frontend generates the mutations for each .cpp, it seems to generate mutations in the .cpp test files as well.

Generating mutations in the .cpp test files is ok in principle.
But given that one has finite time and mutation testing is very time consuming, I would like to prioritize the mutations in the actual library, not in the test code.

Is this possible? can I pass a pattern of files (in this case headers, mylib/include/*.hpp) in which mutations are allowed?

Does it make sense?
If it is not possible now, can it be a good feature request?

@AlexDenisov
Copy link
Member

It's possible, we have some file path filters includePaths/excludePaths, here is an example https://mull.readthedocs.io/en/0.24.0/tutorials/ControlMutationsTutorial.html#file-path-filters

@correaa
Copy link
Author

correaa commented Dec 19, 2024

so, if I have a structure like this

  • mylib
    • mull.yml
    • include
      • mylib.hpp
    • test
      • test1.cpp
      • test2.cpp
    • build

Is this enough?

excludePaths:
  - test*

@AlexDenisov
Copy link
Member

I think

excludePaths:
  - .*test.*

should do, but there it only one way to find out 😄

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