add mention of tinytest

booknews.Rmd

@@ -2,6 +2,8 @@
 
 ## dev version
 
+- 2025/07/09, add mention of tinytest. (#904)
+
 - 2025-07-01, many typo fixes and English language improvements (#912, `@Moohan`)
 
 - 2025-03-11, document drawbacks of renaming widely used package (#831)

pkg_building.Rmd

@@ -344,7 +344,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.