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

Demonstrate how to gather code coverage for web tests #931

Closed
alexeagle opened this issue Jul 22, 2019 · 10 comments
Closed

Demonstrate how to gather code coverage for web tests #931

alexeagle opened this issue Jul 22, 2019 · 10 comments
Labels
Can Close? We will close this in 30 days if there is no further activity

Comments

@alexeagle
Copy link
Collaborator

Should serve to answer https://stackoverflow.com/questions/56556944/how-to-measure-coverage-when-running-typescript-tests-using-karma-and-bazel and also probably will reproduce the issues described there.

@iirina
Copy link

iirina commented Oct 8, 2019

Unfortunately there are no updates in bazel coverage land and there is no future work planned at this time. For this particular use case I can recommend using aspects to collect the transitive source files. An aspect can be attached to karma_web_test_suite. The aspect can collect sources and propagate through all dependencies attributes. There is an advance example which uses an aspect to count the files in the transitive path. Let me know if this is reasonable or if there are further questions.

@alexeagle
Copy link
Collaborator Author

Thanks for replying!
Sure, we already have an aspect here that gathers the source files, and we know how to instrument the app for coverage. The problem is we have no way to report the result, other than write something to TEST_UNDECLARED_OUTPUTS, and as you know that means you can't get coverage data spanning targets/languages.

But if bazel coverage is destaffed then I guess that answers the question and we'll have to write our own coverage tooling that presents the results...

@iirina
Copy link

iirina commented Oct 8, 2019

Thanks @alexeagle. The test runner creates COVERAGE_OUTPUT_FILE as an output for coverage invocations and COVERAGE_DIR for coverage generated files, but the variables are not exposed to Skylark. We can look into what it takes to expose them.

@Toxicable
Copy link

We'd also like to apply the same coverage stratergy for nodejs test coverage, only it uses a slightly different instrumentation method, but transforms are easy.

@iirina I don't know if we need those variables exposed to skylark, although im sure we'll need them there eventually, but just having them avilable to the program being instrumented I think would get us there.
In my testing process.env.COVERAGE_DIR (in a JS program) was never defiend when running under bazel coverage - is there some flag I need to enable?

If you could take a quick look over: https://github.com/bazelbuild/rules_nodejs/pull/1135/files
It's roughly how we'd collect coverage in nodejs and also has a script for processing, merging and writing reports

@Toxicable Toxicable mentioned this issue Dec 21, 2019
4 tasks
@sgammon
Copy link
Contributor

sgammon commented Feb 18, 2020

@alexeagle / @iirina with the release of bazel 2.1.0 and the associated coverage fixes, could i give this issue a bump?

just like the poster on SO says, i've got it to a point where i can run coverage and generate lcov reports. i just need to figure out where to put the report so i can trigger it being merged with the combined report

@Toxicable
Copy link

@sgammon I've integrated bazel coverage into rules_nodejs and @bazel/jasmine in #1135
Take a look there, specifically at coverage_runner.js on where and how to handle the coverage data.

@sgammon
Copy link
Contributor

sgammon commented Feb 18, 2020

@Toxicable thank you!! i'll take a look

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

@github-actions github-actions bot added the Can Close? We will close this in 30 days if there is no further activity label Oct 15, 2020
@github-actions
Copy link

This issue was automatically closed because it went two weeks without a reply since it was labeled "Can Close?"

@thakkarkrutika22
Copy link

Hi,
I'm using this rule - ts_web_test_suite to run angular unit test cases with bazel.

ts_web_test_suite(
name = "unit_test",
tags = ["native", "no-bazelci"],
srcs = [
# We are manaully adding a browserify generated named UMD date-fns bundle here that
# was generated in our package.json postinstall step. This is a temporary work-around
# to get commonjs modules & npm packages working with ts_web_test_suite. A more ergonomic
# solution is planned for Angular v8. See https://github.com//issues/646.
"@npm//date-fns:date-fns.umd.js",
],
# do not sort
bootstrap = [
"@npm//:node_modules/zone.js/dist/zone-testing-bundle.js",
"@npm//:node_modules/reflect-metadata/Reflect.js",
],
browsers = [
"@io_bazel_rules_webtesting//browsers:chromium-local",
# TODO(gregmagolan): re-enable firefox testing once fixed
# See https://github.com/bazelbuild/rules_typescript/issues/296
#"@io_bazel_rules_webtesting//browsers:firefox-local",
],
runtime_deps = [
"//ui/src:initialize_testbed",
],
deps = [
":test",
"//ui/src:rxjs_umd_modules",
],
)

And I'm running this command to find the coverage report using lcov.
bazel coverage --combined_report=lcov //ui/...

But the _coverage_report.dat file generated here is empty.

Can anyone help with this?

@thakkarkrutika22 thakkarkrutika22 mentioned this issue Feb 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Can Close? We will close this in 30 days if there is no further activity
Projects
None yet
Development

No branches or pull requests

5 participants