You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

coverage.md 2.4KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. Coverage collection explained
  2. =============================
  3. Hi mate. In short, you don't wanna know this. Believe me, you don't. Please, close this file and forget about it.
  4. Surely? You still here?
  5. Please, stop it until it's too late.
  6. You were warned.
  7. Preamble
  8. --------
  9. RSPAMD is written mainly in two languages: C and Lua. Coverage for each of them is being collected using different
  10. tools and approaches and is sent into [coveralls.io](https://coveralls.io).
  11. Each approach is not quite compatible to other tools. This document describes how we crutch them to work together.
  12. C coverage
  13. ----------
  14. In general, pretty boring. When you run `cmake` with "-DENABLE_COVERAGE=ON" flag, it adds "--coverage" flag to both
  15. CFLAGS and LDFLAGS. So that each run of generated binary will create `*.gcda` file containing coverage data.
  16. However, there are some moment to highlight:
  17. - RSPAMD is run under "nobody" user. Hence, directories and files should be writable for this user.
  18. - To make it possible, we explicitly run `umask 0000` in "build" and "functional" stages in .circleci/config.yml
  19. - After run, we persist coverage data in "coverage.${CIRCLE\_JOB}.dump" during this build flow, see `capture_coverage_data`,
  20. to use it on the final stage.
  21. - we use `cpp-coveralls` because it is able to save data for coveralls without actually sending it. We send on our own
  22. along with Lua-coverage.
  23. Lua coverage
  24. ------------
  25. Lua coverage is collected for unit-tests and functional test suite.
  26. First part contains nothing interesting, just see `test/lua/tests.lua`.
  27. "Functional" part is completely unobvious.
  28. 1. Coverage collecting is initiated and dumped in `test/functional/lua/test_coverage.lua` (there are a lot of comments inside).
  29. This file should be included on the very early stage of test run. Usually it's included via config.
  30. 2. Coverage is dumped into ${TMPDIR}/%{worker_name}.luacov.stats.out
  31. 3. All worker coverage reports are merged into `lua_coverage_report.json` (see `collect_lua_coverage()`)
  32. 4. finally, `lua_coverage_report.json` is persisted in build flow (see `functional` stage)
  33. Altogether
  34. ----------
  35. Finally, we get all the reports:
  36. - `coverage.functional.dump`
  37. - `coverage.rspamd-test.dump`
  38. - `lua_coverage_report.json`
  39. - `unit_test_lua.json`
  40. and merge them and send the resulting report using `test/functional/util/merge_coveralls.py`. Also, this scripts maps installed
  41. paths into corresponding repository paths and removes unneeded files (i.e. test sources).