add mention of tinytest (#922)

* add mention of tinytest

* es translation

* Update pkg_building.es.Rmd

---------

Co-authored-by: Yanina Bellini Saibene <yabellini@gmail.com>

Author: maelle

booknews.Rmd

@@ -2,6 +2,8 @@
 
 ## dev version
 
+- 2025-07-09, add mention of tinytest. (#904)
+
 - 2025-07-09, add mention of the allcontributors package. (#899)
 
 - 2025-07-09, stop recommending the use of the rOpenSci forum for package discussions. (#898)

pkg_building.Rmd

@@ -348,7 +348,9 @@ 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. 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. [More information](https://r-pkgs.org/tests.html).
+- 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).
+
+- 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. [More information](https://r-pkgs.org/tests.html).
 
 - Tests should be easy to understand, and as self-contained as possible. When using testthat, avoid using code outside of `test_that()` blocks (such as pre-processing steps). We recommend reading the [high-level principles for testing](https://r-pkgs.org/testing-design.html#sec-testing-design-principles) in the R Packages book.
 

pkg_building.es.Rmd

@@ -394,8 +394,9 @@ 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*.
-  Intenta escribir *tests* a medida que escribas cada nueva funció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).
+
+-  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).