Покрытие кода покрытия в Rails вводит в заблуждение

Question

В настоящее время мы используем Coveralls для покрытия кода наших проектов Rails. Результаты покрытия, которые он дает нам, действительно ненадежны. Я неоднократно обнаружил классы, которые не были специфицированы, написанные спецификации для них, а затем наблюдали, как покрытие действительно падает. Это связано с тем, что Coveralls проверяет только классы, загруженные вашими спецификациями. Поэтому, если для класса нет спецификации, он исключается из статистики покрытия. Это, очевидно, не идеально. Есть ли способ обойти это поведение? Я пытаюсь усилить акцент на тестировании в своей команде, и это довольно сложно, когда это создает ложное чувство безопасности.

Answer 1

Я видел две причины, по которым статистика покрытия являются ненадежными в Комбинезоны (и аналогичный сервис Codecov):

• Когда в прошлом я использовал его, Комбинезоны должно было быть сказано, что тестовый набор был распараллеливание. Если не будет получено никаких предупреждений, Coveralls отобразит частичные результаты. Чтобы этого избежать, вы можете сообщить Coveralls, что ваш параллельный набор тестов завершен. См the docs подробности, но кратко:

  • установить переменные окружения COVERALLS_PARALLEL=true на вашем CI сервере
  • POST { "payload": { "build_num": 1234, "status": "done" } } к https://coveralls.io/webhook?repo_token=(your repo token) в конце сборки. (Некоторые услуги хостинга CI выяснить полезную нагрузку автоматически.)

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

Что касается полностью непроверенных классов, отсутствующих в вашем отчете о покрытии, это не относится к Coveralls. Если вы хотите быть уверенным, что все классы загружены, load them eagerly before running your tests. Неиспользованные классы и методы часто не используются, поэтому аудит вашего приложения с детектором мертвого кода, например debride, также может стать хорошим шагом на пути к лучшему охвату.