From 863e6505cdd3323a136c1dbe5f997607614370b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ABlle=20Salmon?= Date: Fri, 12 Jun 2026 11:36:58 +0200 Subject: [PATCH 1/4] add testit as a testthat alternative --- booknews.Rmd | 1 + pkg_building.Rmd | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/booknews.Rmd b/booknews.Rmd index 078494bbc..c43c70cf9 100644 --- a/booknews.Rmd +++ b/booknews.Rmd @@ -2,6 +2,7 @@ ## Dev version +- 2026-06-12, add mention of testit (#1014). - 2026-05-21, clarify that stats must start with a pre-sub (#1011). - 2026-05-21, add comment on updating Airtable rev-prod for new editors (#1005). - 2026-05-21, update docs to require pkg websites at submission (#1004). diff --git a/pkg_building.Rmd b/pkg_building.Rmd index ce8dc166c..b0ceffe8a 100644 --- a/pkg_building.Rmd +++ b/pkg_building.Rmd @@ -413,7 +413,7 @@ For how to update your DESCRIPTION file, see the [R packages book](https://r-pkg - It is good practice to write unit tests for all functions, and all package code in general, ensuring key functionality is covered. Test coverage below 75% will likely require additional tests or explanation before being sent for review. -- We recommend using [testthat](https://testthat.r-lib.org/) for writing tests. An alternative is [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html). +- We recommend using [testthat](https://testthat.r-lib.org/) for writing tests. Alternatives includes [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) or [testit](https://yihui.org/en/2026/05/testthat-to-testit/). - Strive to write tests as you write each new function. This serves the obvious need to have proper testing for the package, but allows you to think about various ways in which a function can fail, and to *defensively* code against those. From 16621405fc97d73cbba05fbe453512c174c64b87 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ABlle=20Salmon?= Date: Fri, 12 Jun 2026 14:53:41 +0200 Subject: [PATCH 2/4] add translations --- pkg_building.es.Rmd | 4 +--- pkg_building.pt.Rmd | 6 +----- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/pkg_building.es.Rmd b/pkg_building.es.Rmd index 70d803c51..f1fa2b407 100644 --- a/pkg_building.es.Rmd +++ b/pkg_building.es.Rmd @@ -2,7 +2,6 @@ aliases: - building.html --- - # Guía de empaquetado {#building} ```{block, type="summaryblock"} @@ -413,8 +412,7 @@ Para saber cómo actualizar tu archivo DESCRIPTION, consulta el libro [*R packag - Es una buena práctica escribir *tests* unitarios para todas las funciones, y para todo el código del paquete en general, asegurando que se cubra las funcionalidades clave. Si la cobertura de los *tests* en tu paquete está por debajo del 75% probablemente requerirá *tests* adicionales o una explicación de la baja cobertura antes de ser enviado para su revisión. -- Recomendamos utilizar [testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otro paquete que se puede usar es [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html). - +- Recomendamos utilizar [ testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otros paquetes que se pueden usar son [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) y [testit](https://yihui.org/en/2026/05/testthat-to-testit/). - Intenta escribir *tests* a medida que escribas cada nueva función. Esto responde a la necesidad obvia de tener *tests* adecuados para el paquete, pero te permite pensar en varias formas en las que una función puede fallar, y programar *defensivamente* contra esas fallas. [Más información sobre *tests*](https://r-pkgs.org/tests.html). diff --git a/pkg_building.pt.Rmd b/pkg_building.pt.Rmd index aa12ce4e5..5e75ec293 100644 --- a/pkg_building.pt.Rmd +++ b/pkg_building.pt.Rmd @@ -2,7 +2,6 @@ aliases: - building.html --- - # Guia de desenvolvimento de pacotes {#building} ```{block, type="summaryblock"} @@ -361,8 +360,7 @@ Para saber como atualizar seu arquivo DESCRIPTION, consulte [o livro *R packages - É uma boa prática escrever testes unitários para todas as funções e para todo o código do pacote em geral, garantindo que a funcionalidade principal seja coberta. Se a cobertura de testes em seu pacote está abaixo de 75%, provavelmente exigirá testes adicionais ou explicações antes de ser enviado para revisão. -- Recomendamos o uso do [pacote testthat](https://testthat.r-lib.org/) para escrever testes. Uma alternativa é o [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html). - +- Recomendamos o uso do [ testthat](https://testthat.r-lib.org/) para escrever testes. Outras opções incluem [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) ou [testit](https://yihui.org/en/2026/05/testthat-to-testit/). - Se esforce para escrever testes ao escrever cada nova função. Isso atende à necessidade óbvia de ter um teste adequado para o pacote, mas permite que você pense sobre as várias maneiras pelas quais uma função pode falhar e programe *defensivamente* contra essas falhas. [Mais informações sobre testes](https://r-pkgs.org/tests.html). - Os testes devem ser fáceis de entender e ser tão autocontidos quanto possível. Ao usar o testthat, evite usar código fora do `test_that()` (como etapas de pré-processamento). Recomendamos a leitura da seção [*"high-level principles for testing"* (princípios de alto nível para testes)](https://r-pkgs.org/testing-design.html#sec-testing-design-principles) no *livro R Packages*. @@ -562,5 +560,3 @@ Se você pretende que seu pacote seja enviado para o Bioconductor ou se o pacote #### MOOCs {#moo-cs} Existe um [especialização do Coursera correspondente ao livro escrito por Roger Peng, Sean Kross e Brooke Anderson](https://fr.coursera.org/specializations/r), com um curso específico sobre pacotes R. - - From 935b9517ee6b7e48060c039d789f80a6867999a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ABlle=20Salmon?= Date: Fri, 12 Jun 2026 15:07:53 +0200 Subject: [PATCH 3/4] Update pkg_building.es.Rmd Co-authored-by: Yanina Bellini Saibene --- pkg_building.es.Rmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pkg_building.es.Rmd b/pkg_building.es.Rmd index f1fa2b407..95314b2c3 100644 --- a/pkg_building.es.Rmd +++ b/pkg_building.es.Rmd @@ -412,7 +412,7 @@ Para saber cómo actualizar tu archivo DESCRIPTION, consulta el libro [*R packag - Es una buena práctica escribir *tests* unitarios para todas las funciones, y para todo el código del paquete en general, asegurando que se cubra las funcionalidades clave. Si la cobertura de los *tests* en tu paquete está por debajo del 75% probablemente requerirá *tests* adicionales o una explicación de la baja cobertura antes de ser enviado para su revisión. -- Recomendamos utilizar [ testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otros paquetes que se pueden usar son [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) y [testit](https://yihui.org/en/2026/05/testthat-to-testit/). +- Recomendamos utilizar [testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otros paquetes que se pueden usar son [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) y [testit](https://yihui.org/en/2026/05/testthat-to-testit/). - Intenta escribir *tests* a medida que escribas cada nueva función. Esto responde a la necesidad obvia de tener *tests* adecuados para el paquete, pero te permite pensar en varias formas en las que una función puede fallar, y programar *defensivamente* contra esas fallas. [Más información sobre *tests*](https://r-pkgs.org/tests.html). From 3115911c7a7a64851c67fae4fa009f23b78fe175 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ma=C3=ABlle=20Salmon?= Date: Thu, 25 Jun 2026 13:18:43 +0200 Subject: [PATCH 4/4] Update pkg_building.pt.Rmd Co-authored-by: Beatriz Milz <42153618+beatrizmilz@users.noreply.github.com> --- pkg_building.pt.Rmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pkg_building.pt.Rmd b/pkg_building.pt.Rmd index 5e75ec293..b96edd8d9 100644 --- a/pkg_building.pt.Rmd +++ b/pkg_building.pt.Rmd @@ -360,7 +360,7 @@ Para saber como atualizar seu arquivo DESCRIPTION, consulte [o livro *R packages - É uma boa prática escrever testes unitários para todas as funções e para todo o código do pacote em geral, garantindo que a funcionalidade principal seja coberta. Se a cobertura de testes em seu pacote está abaixo de 75%, provavelmente exigirá testes adicionais ou explicações antes de ser enviado para revisão. -- Recomendamos o uso do [ testthat](https://testthat.r-lib.org/) para escrever testes. Outras opções incluem [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) ou [testit](https://yihui.org/en/2026/05/testthat-to-testit/). +- Recomendamos o uso do [pacote testthat](https://testthat.r-lib.org/) para escrever testes. Outras opções incluem os pacotes [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) ou [testit](https://yihui.org/en/2026/05/testthat-to-testit/). - Se esforce para escrever testes ao escrever cada nova função. Isso atende à necessidade óbvia de ter um teste adequado para o pacote, mas permite que você pense sobre as várias maneiras pelas quais uma função pode falhar e programe *defensivamente* contra essas falhas. [Mais informações sobre testes](https://r-pkgs.org/tests.html). - Os testes devem ser fáceis de entender e ser tão autocontidos quanto possível. Ao usar o testthat, evite usar código fora do `test_that()` (como etapas de pré-processamento). Recomendamos a leitura da seção [*"high-level principles for testing"* (princípios de alto nível para testes)](https://r-pkgs.org/testing-design.html#sec-testing-design-principles) no *livro R Packages*.