add testit as a testthat alternative

booknews.Rmd

@@ -2,6 +2,7 @@
 
 ## Dev version
 
+- 2026-06-12, add mention of testit (#1014).
 - 2026-05-29, link in reviewer guide to stats template for stats reviews (#1012)
 - 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).

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. 

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

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 [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*.
@@ -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.
-
-