la distribución de paquete de R que contiene pruebas de unidad

Question

así que decidí poner mis pocas funciones R en un paquete y estoy leyendo / aprendizaje escritura R Extensión .

es obvio que se queja de una cantidad de cosas que no estoy haciendo bien.

después de bastante google, estoy disparando algunas preguntas aquí, éste es sobre el estilo de la prueba: Estoy utilizando Runit y me gusta que tienen pruebas como cerca posible del código que se está ensayando. de esta manera no se olvidará de las pruebas y utilizar las pruebas como parte de la documentación técnica.

por ejemplo:

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

pero R CMD check nota temática líneas, como éste:

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

y se queja de mí, no documentar las funciones de prueba.

Realmente no quiero añadir documentación de las funciones de prueba y que sin duda preferiría no tener que agregar una dependencia al paquete Runit.

¿cómo cree que debería examinar esta cuestión?

Answer 1

Cuando estás poniendo las pruebas unitarias? No se puede poner en el directorio R. Un enfoque más estándar es ponerlos bajo inst\unitTests. Echar un vistazo a esta página wiki-R con respecto a la configuración.

Como alternativa, puede especificar qué archivos se pueden exportar en el espacio de nombres, y por extensión, qué funciones deben y no deben ser documentadas.

Más allá de eso, lo ideal es que debe tener sus pruebas ejecutar cuando R CMD CHECK se llama; eso es parte del diseño. En cuyo caso, se debe crear un script de prueba para llamar a sus pruebas en un directorio tests separada. Y que tendrá que cargar el paquete Runit en ese guión (pero no es necesario para que sea una dependencia de su paquete).

Editar 1:

En cuanto a su fracaso porque no puede encontrar la función checkEquals: me gustaría cambiar a funcionar a ser como este:

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 esta forma el paquete se carga cuando la función se llama o se le informará al usuario que es necesario el paquete.

Editar 2:

"escritura R Extensiones" :

  

Tenga en cuenta que todos los objetos de nivel de usuario en un paquete deben estar documentados; si un paquete paquete contiene objetos de nivel de usuario que son para uso “interno” única, se debe proporcionar un archivo PKG-internal.Rd que documenta todos esos objetos, y claramente establece que éstos no están destinados a ser llamado por el usuario. Véase, por ejemplo las fuentes de rejilla paquete en la distribución R para un ejemplo. Tenga en cuenta que los paquetes que utilizan ampliamente los objetos internos deben ocultar los objetos en un espacio de nombres, cuando no necesitan ser documentados (ver espacios nombre del paquete).

Puede utilizar el archivo PKG-internal.Rd como una opción, pero si va a tener muchos objetos ocultos, esto suele ser manejado en las declaraciones del espacio de nombres.

Answer 2

¿Se cargó el paquete RUnit?

Su mejor apuesta es, probablemente, a la vista de un paquete que contiene el código existente utilizando RUnit.