Распространение R-пакета, содержащего модульные тесты

Question

, поэтому я решил, что поместил бы свои несколько R-функций в пакет, и я читаю/изучаю Writing R Extension.

он явно жалуется на то, что я не делаю правильно.

после достаточного поиска в Google, я задаю несколько вопросов здесь, этот вопрос касается стиля тестирования: я использую RUnit, и мне нравится иметь тесты как можно ближе к тестируемому коду. таким образом, я не буду забывать о тестах, и я использую тесты как часть технической документации.

, например:

fillInTheBlanks <- function(S) { 
    ## NA in S are replaced with observed values 

    ## accepts a vector possibly holding NA values and returns a vector 
    ## where all observed values are carried forward and the first is 
    ## carried backward. cfr na.locf from zoo library. 
    L <- !is.na(S) 
    c(S[L][1], S[L])[1 + cumsum(L)] 
} 

test.fillInTheBlanks <- function() { 
    checkEquals(fillInTheBlanks(c(1, NA, NA, 2, 3, NA, 4)), c(1, 1, 1, 2, 3, 3, 4)) 
    checkEquals(fillInTheBlanks(c(1, 2, 3, 4)), c(1, 2, 3, 4)) 
    checkEquals(fillInTheBlanks(c(NA, NA, 2, 3, NA, 4)), c(2, 2, 2, 3, 3, 4)) 
} 

но R CMD check вопросы ЗАМЕТЬТЕ линии, как это:

test.fillInTheBlanks: no visible global function definition for 
    ‘checkEquals’ 

и жалуется мне не документировать функции тестирования.

Я действительно не хочу добавлять документацию для тестовых функций, и я определенно предпочел бы не добавлять зависимость к пакету RUnit.

Как вы думаете, я должен рассмотреть эту проблему?

Answer 1

Куда вы проводите единичные испытания? Возможно, вы не захотите разместить их в каталоге R. Более стандартный подход заключается в том, чтобы поставить их под inst\unitTests. Посмотрите на this R-wiki page regarding the configuration.

В качестве альтернативы вы можете указать, какие файлы будут экспортированы в вашем NAMESPACE, а также расширения, какие функции должны и не должны документироваться.

Кроме того, в идеале вы должны провести тесты, когда вызывается R CMD CHECK; это часть дизайна. В этом случае вы должны создать тестовый скрипт для вызова своих тестов в отдельном каталоге tests. И вам нужно будет загрузить пакет RUnit в этот скрипт (но вам не нужно зависеть от вашего пакета).

Edit 1:

Что касается вашего отказа, потому что он не может найти функцию checkEquals: Я хотел бы изменить вы действуете, чтобы быть похожим на это:

test.fillInTheBlanks <- function() { 
    require(RUnit) 
    checkEquals(fillInTheBlanks(c(1, NA, NA, 2, 3, NA, 4)), c(1, 1, 1, 2, 3, 3, 4)) 
    checkEquals(fillInTheBlanks(c(1, 2, 3, 4)), c(1, 2, 3, 4)) 
    checkEquals(fillInTheBlanks(c(NA, NA, 2, 3, NA, 4)), c(2, 2, 2, 3, 3, 4)) 
} 

Таким образом, пакет загружается при вызывается функция или она сообщит пользователю, что пакет необходим.

Edit 2:

От "Writing R Extensions":

Заметим, что все объекты пользовательского уровня в пакете должны быть документированы; если пакет pkg содержит объекты пользовательского уровня, которые предназначены только для «внутреннего» использования, он должен предоставить файл pkg-internal.Rd, который документирует все такие объекты и четко заявляет, что они не предназначены для вызова пользователем. См. источники для пакетной сетки в R-распределении для примера. Обратите внимание, что пакеты, которые широко используют внутренние объекты, должны скрывать эти объекты в пространстве имен, когда их не нужно документировать (см. Пространство имен пакетов).

Вы можете использовать файл pkg-internal.Rd как один из параметров, но если вы намерены иметь много скрытых объектов, это обычно обрабатывается в объявлениях в NAMESPACE.

Answer 2

Вы загрузили пакет RUnit?

Ваш лучший выбор - это, вероятно, посмотреть на пакет, содержащий существующий код, с помощью RUnit.