Skip to content

add mention of tinytest #922

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

add mention of tinytest #922

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
afda112
add mention of tinytest
maelle Jul 9, 2025
6088084
es translation
maelle Jul 11, 2025
6d98bba
Update pkg_building.es.Rmd
yabellini Jul 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions booknews.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
4 changes: 3 additions & 1 deletion pkg_building.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
5 changes: 3 additions & 2 deletions pkg_building.es.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -395,8 +395,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).

Expand Down