#669 - Add code coverage support improve

[miroslavpojer]

• Used Absa fork of JaCoCo solution - with scala method filtering.
• Added support for code coverage GitHub action check as part of PR.

Closes #669

[github-actions[bot]]

JaCoCo code coverage report

There is no coverage information present for the Files changed

Total Project Coverage	42.09%	:green_apple:

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[cerveada]

Does this coverage take into account the integration-tests or just the standard unit tests?

[miroslavpojer]

Does this coverage take into account the integration-tests or just the standard unit tests?

Total project coverage is measured and counted only for core module in project. For coverage measuring are used tests which are inside of this module.

[cerveada]

This project is somewhat atypical in that it relies heavily on integration tests. A huge portion of logic here is matching and extracting objects coming from Spark, and we need to test that it works for every version of Spark and Scala supported.

So unit test are useless for a big part of the code, we used them to test the internal logic of course, but that is the smaller part of the codebase.

I think we need to either include the integration test in the metric (not sure if it's possible) or drop the requirement for minimal coverage percentage.

[miroslavpojer]

This project is somewhat atypical in that it relies heavily on integration tests. A huge portion of logic here is matching and extracting objects coming from Spark, and we need to test that it works for every version of Spark and Scala supported.

So unit test are useless for a big part of the code, we used them to test the internal logic of course, but that is the smaller part of the codebase.

I think we need to either include the integration test in the metric (not sure if it's possible) or drop the requirement for minimal coverage percentage.

I understand. You are missing crossbuild feature in maven. I do not know the way how to connect two modules to measure code coverage this way. The basic idea is to measure one module only. I see three options:

• switch project to sbt where is cross build present and applied by several projects in AbsaOSS
• drop entire jacoco GH action
• lower GH blocking percentage to acceptable value

[cerveada]

Cross-build is not a big factor here. The core issue is that we care about the test coverage (unit + integration) but we measure unit only.

[miroslavpojer]

Cross-build is not a big factor here. The core issue is that we care about the test coverage (unit + integration) but we measure unit only.

Yes, until integration test will be outside of measured module.