#r #testthat
#r #модульное тестирование #testthat
Вопрос:
Я использую testthat для проверки кода в моем пакете. Некоторые из моих тестов предназначены для базовой функциональности, такой как конструкторы и геттеры. Другие предназначены для сложной функциональности, которая строится поверх базовой функциональности. Если базовые тесты завершаются неудачей, то ожидается, что сложные тесты завершатся неудачей, поэтому нет смысла проводить дальнейшее тестирование.
Возможно ли:
- Убедитесь, что базовые тесты всегда выполняются первыми
- Сделать сбой теста остановкой процесса тестирования
Ответ №1:
Отвечая на ваш вопрос, я не думаю, что это можно определить иначе, чем с помощью соответствующего буквенно-цифрового наименования ваших test-*.R файлов.
Из testthat источника это функция, которую test_package вызывает через test_dir для получения тестов:
find_test_scripts <- function(path, filter = NULL, invert = FALSE, ...) {
files <- dir(path, "^test.*\.[rR]$", full.names = TRUE)
В любом случае, что плохого в том, чтобы просто позволить сложной задаче сначала завершиться неудачей?
Комментарии:
1. «Что не так …» ? Моя первая мысль — «время вычислять», ищу быстрый сбой вместо долгого ожидания. (Одному из моих проектов неизбежно требуется 15-20 минут для выполнения всех тестов. Кроме того, у меня есть зависимости между тестами: один тест настраивает среду, другие тесты повторно используют компоненты. Разбиение тестов на несколько файлов полезно в моем случае, по общему признанию, не для всех.)
2. Справедливое замечание. Сложно, но возможно разделить тесты, только некоторые из которых выполняются при тестировании на CRAN, если это важно для вас. Для запуска определенного набора тестов требуется только аргумент командной строки, но он вообще не интегрируется с Rstudio, а совместное использование тестового содержимого между двумя группами или использование testthat, вероятно, потребовало бы большого количества обслуживания и сбоев. Таким образом, я согласен с вами!
Ответ №2:
Что касается порядка тестов, вы можете использовать конфигурацию testthat в файле ОПИСАНИЯ, чтобы определить порядок тестирования (по файлу) — Как предлагает документация
По умолчанию testthat запускает тестовые файлы в алфавитном порядке. Если у вас есть несколько тестовых файлов, которые занимают больше времени, чем остальные, то это может быть не самый лучший порядок. В идеале медленные файлы должны запускаться первыми, поскольку весь набор тестов займет по меньшей мере столько же времени, сколько самый медленный тестовый файл. Вы можете изменить порядок с помощью опции Config/testthat/start-first в ОПИСАНИИ. Например, testthat в настоящее время имеет:
Config/testthat/start-first: watcher, parallel*
Ответ №3:
Недавняя (иш) разработка для тестирования — это параллельная обработка тестов
Это может не подойти в вашем случае, поскольку звучит так, как будто у вас могут быть сложные взаимозависимости между тестами. Если бы вы могли изолировать свои тесты (я думаю, что в любом случае это было бы более обычным случаем), то параллельная обработка — отличное решение, поскольку это должно ускорить общее время обработки, а также, вероятно, показать вам, что «быстрые» тесты завершаются неудачей до завершения «медленных» тестов.