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

Allow modifying configuration through extensions? #6083

Open
pkly opened this issue Dec 12, 2024 · 2 comments
Open

Allow modifying configuration through extensions? #6083

pkly opened this issue Dec 12, 2024 · 2 comments
Labels
feature/configuration feature/test-runner CLI test runner type/enhancement A new idea that should be implemented

Comments

@pkly
Copy link

pkly commented Dec 12, 2024

As far as I can tell it is not possible to modify the configuration by means other than cli and xml.
In our case we'd like to detect what testsuite is running, and update the coverage exclusion rules.

I've looked over but it seems that both 10 and 11 only have a cli and merger from xml for the configuration, but at least the extensions could be loaded and ran to re-modify the config (or at least the configuration).

It is a bit of a mess, since the cli and xml load a config, then would run an extension, which would then update the config and then only that would be ran.

So CLI -> XML -> Load extensions -> parse config -> run

Or, create a separate extension listener type of some sort to only allow config modification, which would also suit our needs.

@pkly pkly added the type/enhancement A new idea that should be implemented label Dec 12, 2024
@sebastianbergmann
Copy link
Owner

As far as I can tell it is not possible to modify the configuration by means other than cli and xml.

Your assumption is correct. The default configuration is modified by what is loaded from the XML configuration and what is parsed from the CLI options and arguments is applied on top of that.

In our case we'd like to detect what testsuite is running, and update the coverage exclusion rules.

May I ask you to elaborate on your use case?

@pkly
Copy link
Author

pkly commented Dec 12, 2024

We run separate jobs for test suites, as of now it's not possible to setup separate exclusions in <source> for different test suites.

There's no point in the coverage score being lowered in the unit testsuite just because it didn't test the controllers, which by design, cannot be unit tested (at least in a way that makes sense).

Additionally we'd like to disable coverage for attribute classes, which would be hard to do by hand, since they don't have a suffix like "Attribute" and are spread between different directories.

One thing that could be considered and should be fairly easy to implement is allowing the <source> parameter inside of <testsuite> maybe?
That way we could at least disable some coverage for classes that don't make sense for unit testsuite by directories.

Otherwise an extension would be needed, and I'd simply check which testsuite we're running under and modify the source for CC accordingly.

Edit: added the code tags since GH hid my <tags> (whoops)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/configuration feature/test-runner CLI test runner type/enhancement A new idea that should be implemented
Projects
None yet
Development

No branches or pull requests

2 participants