✨ More proofreading ✨

Author: hadley

vignettes/challenging-tests.Rmd

@@ -20,7 +20,7 @@ snapper$start_file("snapshotting.Rmd", "test")
 Sys.setenv(TESTTHAT_PKG = "testthat")
 ```
 
-This vignette is a quick reference guide for testing challenging functions. It's organised by the problem, rather the than technique used to solve it, so you can quickly skim the whole vignette, spot the problem you're facing, then learn more about useful tools for solving it.
+This vignette is a quick reference guide for testing challenging functions. It's organised by the problem, rather than the technique used to solve it, so you can quickly skim the whole vignette, spot the problem you're facing, then learn more about useful tools for solving it.
 
 ## Options and environment variables
 

vignettes/custom-expectation.Rmd

@@ -33,7 +33,7 @@ expect_length <- function(object, n) {
   if (act_n != n) {
     msg <- c(
       sprintf("Expected %s to have length %i.", act$lab, n),
-      sprintf("Actual length: %i.", act$n)
+      sprintf("Actual length: %i.", act_n)
     )
     return(fail(msg))
   }

vignettes/mocking.Rmd

@@ -158,7 +158,7 @@ Here we pretend that there are no reverse dependencies (revdeps) for the package
 
 ### Managing time
 
-but this either made my tests both slow (because I'd sleep for a second or two) and unreliable (because sometimes more time elapsed than I expected). Eventually I figured out that I could "manually control" time by using a [mocked function](https://github.com/r-lib/httr2/blob/main/tests/testthat/test-req-throttle.R) that returns the value of a variable I control. This allows me to manually advance time and carefully test the implications.
+`httr2::req_throttle()` prevents multiple requests from being made too quickly, using a tool called a leaky token bucket. This tool is inextricably tied to real time because you want to allow more requests as time elapses. So how do you test this? I started by using `Sys.sleep()` but this either made my tests both slow (because I'd sleep for a second or two) and unreliable (because sometimes more time elapsed than I expected). Eventually I figured out that I could "manually control" time by using a [mocked function](https://github.com/r-lib/httr2/blob/main/tests/testthat/test-req-throttle.R) that returns the value of a variable I control. This allows me to manually advance time and carefully test the implications.
 
 You can see the basic idea with a simpler example. Let's first begin with a function that returns the "unix time", the number of seconds elapsed since midnight on Jan 1 1970. This is easy to compute, but will make some computations simpler later as well as providing a convenient function to mock.
 

vignettes/skipping.Rmd

@@ -77,7 +77,7 @@ skip_if_dangerous <- function() {
 ## Embedding `skip()` in package functions
 
 Another potentially useful technique is to build a `skip()` directly into a package function.
-For example take a look at [`pkgdown:::convert_markdown_to_html()`](https://github.com/r-lib/pkgdown/blob/v2.0.7/R/markdown.R#L95-L106), which absolutely, positively cannot work if the Pandoc tool is unavailable:
+For example, take a look at [`pkgdown:::convert_markdown_to_html()`](https://github.com/r-lib/pkgdown/blob/v2.0.7/R/markdown.R#L95-L106), which absolutely, positively cannot work if the Pandoc tool is unavailable:
 
 ```{r eval = FALSE}
 convert_markdown_to_html <- function(in_path, out_path, ...) {
@@ -108,7 +108,7 @@ is_testing <- function() {
 }
 ```
 
-It might look like the code appears to still have a runtime dependency on testthat, because of the call to `testthat::skip()`.
+It might look like the code still has a runtime dependency on testthat, because of the call to `testthat::skip()`.
 But `testthat::skip()` is only executed during a test run, which implies that testthat is installed.
 
 We have mixed feelings about this approach.

vignettes/snapshotting.Rmd

@@ -42,8 +42,8 @@ snapper$start_file("snapshotting.Rmd", "test")
 
 ## Basic workflow
 
-We'll illustrate the basic workflow with a simple function that generates an HTML bullets.
-It can optionally include an `id` attribute, which allows you to construct a link directly to that heading.
+We'll illustrate the basic workflow with a simple function that generates HTML bullets.
+It can optionally include an `id` attribute, which allows you to construct a link directly to that list.
 
 ```{r}
 bullets <- function(text, id = NULL) {
@@ -198,7 +198,7 @@ test_that("you can't add weird things", {
 
 Just be careful: when you set `error = TRUE`, `expect_snapshot()` checks that at least one expression throws an error, not that every expression throws an error. For example, look above and notice that adding a date and factor generated a warning, not an error.
 
-Snapshot tests are particularly important when testing complex error messages, such as those that you might generate with cli. Here's a more realistic example illustrating how you might test `check_unnamed()`, a function that ensures all arguments in `...` are unnnamed.
+Snapshot tests are particularly important when testing complex error messages, such as those that you might generate with cli. Here's a more realistic example illustrating how you might test `check_unnamed()`, a function that ensures all arguments in `...` are unnamed.
 
 ```{r}
 check_unnamed <- function(..., call = parent.frame()) {