Я думаю, что это плохая идея. Вы хотите, чтобы ваш модульный тест проверял одно и только одно. Вместо того чтобы создавать вызов с помощью другого теста, смоделируйте вызов и передайте его в качестве аргумента.
You could pass your command line arguments into an interactive shell with --args and then source('') the script.
$ R --args -v
R version 2.8.1 (2008-12-22)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> require(getopt)
Loading required package: getopt
> opt = getopt(c(
+ 'verbose', 'v', 2, "integer"
+ ));
> opt
$verbose
[1] 1
> source('my_script.R')
You could now use the old browser() function to debug.
Я использую либо стандартные операторы печати, либо интерактивный анализ. Для этого я сначала сохраняю состояние с помощью save ()
, а затем загружаю его в интерактивный сеанс (для которого я использую Emacs / ESS). Это позволяет выполнять интерактивную работу с использованием кода сценария на построчной основе.
Но я часто сначала пишу / тестирую / отлаживаю код в интерактивном режиме, прежде чем развертывать в более маленьком сценарии.
Другой вариант - работать с опциями (ошибкой). Вот простой пример:
options(error = quote({dump.frames(to.file=TRUE); q()}))
Вы можете создать сколь угодно подробный сценарий для ошибки, поэтому вам нужно просто решить, какая информация вам нужна для отладки.
В противном случае, если есть определенные области, которые вас беспокоят (например, подключение к базе данных), а затем заключить их в функцию tryCatch ().