la distribution de colis de R contenant des tests unitaires

Question

donc je décidé que je mettrais mes quelques fonctions de R dans un paquet et je lis / apprentissage écriture R extension.

il se plaint évidemment au sujet d'une quantité de choses que je ne fais pas droit.

après assez googler, je suis mise à feu quelques questions ici, celui-ci est sur le style de test: J'utilise runIt et j'aime avoir des tests le plus près possible du code testé. cette façon je ne vais pas oublier les essais et j'utiliser les tests dans le cadre de la documentation technique.

par exemple:

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))
}

mais R CMD check questions NOTE lignes, comme celui-ci:

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

et il se plaint de ne pas me documenter les fonctions de test.

Je ne veux pas vraiment ajouter de la documentation pour les fonctions de test et je préfèrerais certainement ne pas avoir à ajouter une dépendance à l'ensemble RunIt.

comment pensez-vous que je devrais regarder cette question?

Answer 1

Où mettez-vous vos tests unitaires? Vous voudrez peut-être de ne pas les mettre dans le répertoire R. Une approche plus standard est de les mettre sous inst\unitTests. Jetez un oeil à cette page R-wiki concernant la configuration.

Vous pouvez spécifier quels fichiers seront exportés dans votre espace, et par extension, quelles fonctions doivent et ne doivent pas être documentés.

Au-delà, dans l'idéal, vous devriez avoir vos tests effectués lors de vérifier R CMD est appelé; qui fait partie de la conception. Dans ce cas, vous devez créer un script de test pour appeler vos tests dans un répertoire tests séparé. Et vous devrez charger le paquet RunIt dans ce script (mais vous n'avez pas besoin d'en faire une dépendance de votre forfait).

Edit 1:

En ce qui concerne votre échec parce qu'il ne peut pas trouver la fonction checkEquals: Je vous changer la fonction à être comme ceci:

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))
}

De cette façon, le paquet est chargé lorsque la fonction est appelée ou elle en informe l'utilisateur que le package est nécessaire.

Edit 2:

De "Extensions d'écriture R" :

  

Notez que tous les objets de niveau utilisateur dans un emballage doivent être documentées; si un pkg paquet contient des objets de niveau utilisateur qui sont à usage « interne », il doit fournir un fichier pkg-internal.Rd qui documente tous ces objets, et indique clairement que ceux-ci ne sont pas destinés à être appelé par l'utilisateur. Voir par exemple les sources de réseau de paquets dans la distribution de R pour un exemple. Notez que les paquets qui utilisent des objets internes devraient largement cacher ces objets dans un espace de noms, quand ils ne doivent pas nécessairement être documentés (voir espaces Nom du package).

Vous pouvez utiliser le fichier pkg-internal.Rd comme une option, mais si vous avez l'intention d'avoir de nombreux objets cachés, cela est généralement traitée dans les déclarations dans le namespace.

Answer 2

Avez-vous téléchargé le package RUnit?

Votre meilleur pari est probablement regarder un paquet contenant le code existant en utilisant RUnit.