✨ Proofreading ✨

Author: hadley

vignettes/challenging-tests.Rmd

@@ -28,7 +28,7 @@ If your function depends on options or environment variables, first try refactor
 
 ## Random numbers
 
-Random number generators generate different numbers each time you can them because they update a special `.Random.seed` variable stored in the global environment. You can temporarily set this seed to a known value to make your random numbers reproducible with `withr::local_seed()`, making random numbers a special case of test fixtures. Learn more in `vignette("test-fixtures")`.
+Random number generators generate different numbers each time you call them because they update a special `.Random.seed` variable stored in the global environment. You can temporarily set this seed to a known value to make your random numbers reproducible with `withr::local_seed()`, making random numbers a special case of test fixtures. Learn more in `vignette("test-fixtures")`.
 
 ```{r}
 #| label: random-local-seed

vignettes/mocking.Rmd

@@ -20,7 +20,7 @@ snapper$start_file("snapshotting.Rmd", "test")
 Sys.setenv(TESTTHAT_PKG = "testthat")
 ```
 
-Mocking allows you to temporarily replace the implementation of a function with something that makes it easier to test. It's useful when testing failure scenarios that are hard to generate organically (e.g. what happens if dependency X isn't installed?), making tests more reliable by eliminating potential variability, and making tests faster. It's also general escape hatch for to resolve pretty much any challenging testing problem.
+Mocking allows you to temporarily replace the implementation of a function with something that makes it easier to test. It's useful when testing failure scenarios that are hard to generate organically (e.g. what happens if dependency X isn't installed?), making tests more reliable by eliminating potential variability, and making tests faster. It's also a general escape hatch to resolve pretty much any challenging testing problem.
 
 (If, like me, you're confused as to why you'd want to cruelly make fun of your tests, here mocking is used in the sense of making a fake or simulated version of something, i.e. a mock-up.)
 
@@ -187,7 +187,7 @@ Imagine trying to test this function without mocking! You'd probably think it's
 With mocking, however, I can "manipulate time" by mocking `unix_time()` so that it returns the value of a variable I control. Now I can write a reliable test:
 
 ```{r}
-test_that("elapsed() meausres elapsed time", {
+test_that("elapsed() measures elapsed time", {
   time <- 1
   local_mocked_bindings(unix_time = function() time)
 
@@ -219,8 +219,8 @@ assignInNamespace("my_function", old, "mypackage")
 
 This leads to the two limitations of `local_mocked_bindings()`:
 
-1. The package namespace is locked, which means that you can't add new bindings to it. That means if you want to mock base functions, you have to provide some binding that can be overriden. The easiest way to do this is (e.g.) `mean <- NULL`. This creates a binding that `local_mocked_bindings()` can modify, but because of R's [lexical scoping rules](https://adv-r.hadley.nz/functions.html#functions-versus-variables) this doesn't affect ordinary calls to `mean()`.
+1. The package namespace is locked, which means that you can't add new bindings to it. That means if you want to mock base functions, you have to provide some binding that can be overridden. The easiest way to do this is (e.g.) `mean <- NULL`. This creates a binding that `local_mocked_bindings()` can modify, but because of R's [lexical scoping rules](https://adv-r.hadley.nz/functions.html#functions-versus-variables) this doesn't affect ordinary calls to `mean()`.
 
 1. `::` doesn't use the package namespace, so if you want to mock a function from another package that you call with `::`, you either have to switch from `pkg::fun()` to `fun()` by importing `fun` into your `NAMESPACE` (e.g. with `@importFrom pkg fun`), or create your own wrapper function that you can mock. Typically, one of these options will feel fairly natural.
 
-Overall these limitations feel correct to me: `local_mocked_bindings()` makes it easy to temporarily change the implementation of functions that you have written, while offering workarounds to override the implementations of functions that you others have written in the scope of your package.
+Overall these limitations feel correct to me: `local_mocked_bindings()` makes it easy to temporarily change the implementation of functions that you have written, while offering workarounds to override the implementations of functions that others have written in the scope of your package.

vignettes/skipping.Rmd

@@ -14,7 +14,7 @@ knitr::opts_chunk$set(
 )
 ```
 
-Some times you have tests that you don't want to run in certain circumstances.
+Sometimes you have tests that you don't want to run in certain circumstances.
 This vignette describes how to **skip** tests to avoid execution in undesired environments.
 Skipping is a relatively advanced topic because in most cases you want all your tests to run everywhere.
 The most common exceptions are:
@@ -47,7 +47,7 @@ testthat comes with a variety of helpers for the most common situations:
 
 You can also easily implement your own using either `skip_if()` or `skip_if_not()`, which both take an expression that should yield a single `TRUE` or `FALSE`.
 
-All reporters show which tests as skipped.
+All reporters show which tests are skipped.
 As of testthat 3.0.0, ProgressReporter (used interactively) and CheckReporter (used inside of `R CMD check`) also display a summary of skips across all tests.
 It looks something like this:
 
@@ -57,12 +57,12 @@ It looks something like this:
 ● On CRAN (1)
 ```
 
-You should keep an on eye this when developing interactively to make sure that you're not accidentally skipping the wrong things.
+You should keep an eye on this when developing interactively to make sure that you're not accidentally skipping the wrong things.
 
 ## Helpers
 
 If you find yourself using the same `skip_if()`/`skip_if_not()` expression across multiple tests, it's a good idea to create a helper function.
-This function should start with `skip_` and live in a `test/helper-{something}.R` file:
+This function should start with `skip_` and live in a `tests/testthat/helper-{something}.R` file:
 
 ```{r}
 skip_if_dangerous <- function() {

vignettes/snapshotting.Rmd

@@ -319,7 +319,7 @@ If you need to test graphical output, {vdiffr}. vdiffr is used to test ggplot2,
 ### Snapshotting values
 
 `expect_snapshot()` is the most used snapshot function because it records everything: the code you run, printed output, messages, warnings, and errors.
-If you care about the return value rather than any side-effects, you may might to use `expect_snapshot_value()` instead.
+If you care about the return value rather than any side-effects, you might want to use `expect_snapshot_value()` instead.
 It offers a number of serialisation approaches that provide a tradeoff between accuracy and human readability.
 
 ```{r}

vignettes/test-fixtures.Rmd

@@ -184,7 +184,7 @@ withr::deferred_run()
 #> [1] "hi"
 ```
 
-Finally, `withr::defer()` lets you pick which function to bind the clean up behaviour too. This makes it possible to create helper functions.
+Finally, `withr::defer()` lets you pick which function to bind the clean up behaviour to. This makes it possible to create helper functions.
 
 ### "Local" helpers