Покрытие ржавчины с использованием kcov не выглядит правильным - PullRequest
Новая
       26

Покрытие ржавчины с использованием kcov не выглядит правильным

0 голосов
/ 29 августа 2018

Когда я записываю покрытие кода моего проекта Rust с использованием codecov.io, покрытие отображается неправильно.

  1. Функция unwrap() и концевая скобка не охватываются

    unwrap and end bracket not covered

  2. Объявление функции не рассматривается

    function declaration not covered

Это очень странно.

Я не могу предоставить полный проект для воспроизведения.

Я использую стандартную конфигурацию TravisCI для Rust. Вот мой .travis.yml: 

language: rust
cache: cargo
dist: trusty
sudo: required

rust:
  - stable
  - beta
  - nightly

matrix:
  allow_failures:
    - rust: nightly

script:
  - cargo build --verbose --all
  - cargo test --verbose --all

after_success: |
  wget https://github.com/SimonKagstrom/kcov/archive/master.tar.gz &&
  tar xzf master.tar.gz &&
  cd kcov-master &&
  mkdir build &&
  cd build &&
  cmake .. &&
  make &&
  make install DESTDIR=../../kcov-build &&
  cd ../.. &&
  rm -rf kcov-master &&
  for file in target/debug/myproject-*[^\.d]; do mkdir -p "target/cov/$(basename $file)"; ./kcov-build/usr/local/bin/kcov --exclude-pattern=/.cargo,/usr/lib --verify "target/cov/$(basename $file)" "$file"; done &&
  bash <(curl -s https://codecov.io/bash)
  echo "Uploaded code coverage"

1 Ответ

0 голосов
/ 09 апреля 2019

Предполагая, что поведение Карго и Трэвиса существенно не изменилось с тех пор, как этот вопрос был опубликован, здесь есть пара вещей.

  • Всякий раз, когда изменяется конфигурация сборки, меняется отпечаток вашей сборки, что приводит к полной или частичной перестройке и новому имени файла для полученного двоичного файла в target. По общему признанию, я не знаю тонкостей того, когда и почему это происходит, я просто знаю, что это происходит. На самом деле, для проекта, над которым я работаю, Cargo кажется настолько смущенным одной из зависимостей, что он вызывает перестройку почти каждый раз.
  • Travis 'cache: cargo по умолчанию довольно тупой; он кэширует все $CARGO_HOME и target без исключений. Обратите внимание, что это в сочетании с первым также означает, что эти кэши растут без ограничений, поэтому вам нужно время от времени выбрасывать их или использовать более разумную схему кэширования.
  • for file in target/debug/myproject-*[^\.d] запускает kcov для всех сборок myproject, независимо от того, была ли она недавно построена или из кеша сборки Travis. Старые сборки могут, конечно, иметь разные номера строк, поскольку они были построены из разных (более старых) источников, и охват может быть разным.
  • cover.io объединяет результаты покрытия, выделяя красную строку, если она включена в любой отчет, если только он не охватывается любым (другим) отчетом. Он не показывает никаких признаков того, что номера строк в разных отчетах не совпадают или даже если один из отчетов содержит номера строк, превышающие EOF. На самом деле, насколько я мог найти, он даже не показывает, какие двоичные файлы покрывали / не покрывали номер строки, даже если он имеет эту информацию. Вы должны скачать отчеты XML и интерпретировать их вручную, чтобы увидеть это.

Следовательно, эти непокрытые строки могут (не все?) Происходить из-за того, как Rust компилирует свои двоичные файлы, как подсказывают комментарии к вопросу, но на самом деле могут полностью ссылаться на другой (более старый) исходный файл. Это стало довольно очевидным в нашем проекте через некоторое время ...

borked coverage results

Если это не так очевидно, самый простой способ убедиться в том, что это происходит, - просто выбросить кэш сборок Трэвиса и вызвать перестроение.

Поскольку инкрементные сборки на самом деле не работают для нашего проекта, решение, которое мы использовали, заключалось в том, чтобы Travis просто не кэшировал целевой каталог, как предлагалось здесь . В зависимости от того, насколько ваше время сборки CI зависит от инкрементных сборок, вы можете быть вынуждены сделать что-то более умное.

...