QA/Tests: various code coverage tweaks #331
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While the feedback shown in the `setup-php` step is awesome, it doesn't show the version of Xdebug used when running code coverage, while, in case of issues, the version number of Xdebug is crucial to know. This extra step allows for that information to always be available. I've only added the step to the code coverage job though as that's the only one for which the Xdebug version is relevant.
The functions being tested in these three test classes all use function local `static` variables for optimization. Having the function local `static` variable will often prevent code coverage from being recorded correctly for the code as the code for setting the static will only be run when the function is first called, which may not be in the dedicated test for the function, so it makes code coverage recording highly dependant on the order in which tests are run. In these three cases, I do believe the function local `static` variable is justified (for the time being, benchmarking should be able to determine for sure at some point in the future). To still prevent missed lines in the code coverage reports, I'm moving the tests for these three functions into a separate test suite, which will run first. This should ensure the code which sets the static will be run first when the dedicated tests for these methods are run and should allow the correct registration of code coverage for this code. Mind: if at some point the `executionOrder` configuration would be added to the config/enabled, it needs to be verified how that behaves in combination with multiple test suites. But that's for later. Ref: sebastianbergmann/php-code-coverage#913
... for code which is only in place as defensive coding, but shouldn't be reachable under normal circumstances.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GH Actions/coverage: add extra (debug) step
While the feedback shown in the
setup-phpstep is awesome, it doesn't show the version of Xdebug used when running code coverage, while, in case of issues, the version number of Xdebug is crucial to know.This extra step allows for that information to always be available.
I've only added the step to the code coverage job though as that's the only one for which the Xdebug version is relevant.
Also see: shivammathur/setup-php#610
PHPUnit config: isolate a number of tests from the main test suite
The functions being tested in these three test classes all use function local
staticvariables for optimization.Having the function local
staticvariable will often prevent code coverage from being recorded correctly for the code as the code for setting the static will only be run when the function is first called, which may not be in the dedicated test for the function, so it makes code coverage recording highly dependent on the order in which tests are run.In these three cases, I do believe the function local
staticvariable is justified (for the time being, benchmarking should be able to determine for sure at some point in the future).To still prevent missed lines in the code coverage reports, I'm moving the tests for these three functions into a separate test suite, which will run first.
This should ensure the code which sets the static will be run first when the dedicated tests for these methods are run and should allow the correct registration of code coverage for this code.
Mind: if at some point the
executionOrderconfiguration would be added to the config/enabled, it needs to be verified how that behaves in combination with multiple test suites. But that's for later.Ref: sebastianbergmann/php-code-coverage#913
Tests: add select @codeCoverageIgnore annotations
... for code which is only in place as defensive coding, but shouldn't be reachable under normal circumstances.