Skip to contents

inc.rtests

Este meetup ofrece una visión general del flujo de trabajo para el desarrollo de paquetes, con un enfoque en las pruebas unitarias y CI/CD.

Importancia

Un paquete es un conjunto de convenciones para organizar tu código y los artefactos relacionados: si sigues esas convenciones, obtienes un montón de herramientas gratis. – https://mastering-shiny.org/scaling-packaging.html

Audiencia

Científicos de datos con algo de experiencia escribiendo código y funciones en R, pero con poca o ninguna experiencia en el desarrollo de paquetes en R.

Objetivos

Crear y chequear la infraestructura básica de un paquete:

  • Crear un paquete en R.
  • Chequear la estructura y corregir problemas.
  • Crear un checklist de infraestructura adicional a considerar.
  • Documentar el “home page”, con el objetivo, installación y ejemplo.
  • Configurar checks de estructura en GitHub.
  • Configurar el despliege del website en GitHub.

Crear y probar una función simple:

  • Crear una función simple.
  • Reportar la cobertura.
  • Probarla.
  • Documentarla.
  • Chequear la estructura y corregir problemas.
  • Chequear el website localmente.

Mostrar otras cosas que hicimos pero que no podemos cubrir hoy:

  • Check de integración para una dependencias reversa.
  • El formato “incubadora”.

Flujo de trabajo

https://r-pkgs.org/whole-game.html#review

Demo

En vivo.

Recursos

EN

inc.rtests

This meetup provides an overview of the workflow for package development, focusing on unit testing and CI/CD.

Importance

A package is a set of conventions for organizing your code and related artifacts: if you follow those conventions, you get a bunch of free tools. – https://mastering-shiny.org/scaling-packaging.html

Audience

Data scientists with some experience writing code and functions in R, but with little to no experience in R package development.

Objectives

Create and check the basic infrastructure of a package:

  • Create a package in R.
  • Check the structure and fix issues.
  • Create a checklist of additional infrastructure to consider.
  • Document the “home page,” including the aim, installation, and example.
  • Set up structure checks on GitHub.
  • Set up the deployment of the website on GitHub.

Create and test a simple function:

  • Create a simple function.
  • Report the coverage.
  • Test it.
  • Document it.
  • Check the structure and fix issues.
  • Check the website locally.

Show other things we’ve done but cannot cover today:

  • Integration check for reverse dependencies.
  • The “incubator” format.

Workflow

https://r-pkgs.org/whole-game.html#review

Demo

Live.

Resources