Fix vignette typos (#1215)

* Fix vignette typos

* Wrong function

* Remove doubling

* Plural

* Add missing word

Author: krlmlr

R/snapshot-file.R

@@ -41,7 +41,7 @@
 #' expect_snapshot_file(save_png(hist(mtcars)), "plot.png")
 #' }
 #'
-#' # You'd then also provide a helper that skip tests where you can't
+#' # You'd then also provide a helper that skips tests where you can't
 #' # be sure of producing exactly the same output
 #' expect_snapshot_plot <- function(name, code) {
 #'   # Other packages might affect results

man/expect_snapshot_file.Rd

@@ -16,7 +16,7 @@ set.seed(1014)
 ```
 
 The goal of a unit test is to record the expected output of a function using code.
-This is a powerful technique because because not only does it ensure that code doesn't change unexpectedly, it also expresses the desired behaviour in a way that a human can understand.
+This is a powerful technique because not only does it ensure that code doesn't change unexpectedly, it also expresses the desired behaviour in a way that a human can understand.
 
 However, it's not always convenient to record the expected behaviour with code.
 Some challenges include:
@@ -151,7 +151,7 @@ Within a test, each snapshot expectation is indented by four spaces, i.e. as cod
 
 ### Interactive usage
 
-Because the snapshot output uses the the name of the current test file and the current test, snapshot expectations don't really work when run interactively at the console.
+Because the snapshot output uses the name of the current test file and the current test, snapshot expectations don't really work when run interactively at the console.
 Since they can't automatically find the reference output, they instead just print the current value for manual inspection.
 
 ## Other types of snapshot
@@ -169,9 +169,9 @@ Since they can't automatically find the reference output, they instead just prin
 But that doesn't work for all file types --- for example, what happens if you want to snapshot an image?
 `expect_snapshot_file()` provides an alternative workflow that generates one snapshot per expectation, rather than one file per test.
 Assuming you're in `test-burger.R` then the snapshot created by `expect_snapshot_file(code_that_returns_path_to_file(), "toppings.png")` would be saved in `tests/testthat/_snaps/burger/toppings.png`.
-If a future change in the code creates a a different file it will be saved in `tests/testthat/_snaps/burger/toppings.new.png`.
+If a future change in the code creates a different file it will be saved in `tests/testthat/_snaps/burger/toppings.new.png`.
 
-Unlike `expect_snapshot()` and friends, `expect_snapshot()` can't automatically provide an automatic diff when the test fails.
+Unlike `expect_snapshot()` and friends, `expect_snapshot_file()` can't provide an automatic diff when the test fails.
 Instead you'll need to call `snapshot_review()`.
 This launches a Shiny app that allows you to visually review each change and approve it if it's deliberate:
 

vignettes/snapshotting.Rmd

@@ -22,7 +22,7 @@ knitr::opts_chunk$set(
 >
 > ― Chief Si'ahl
 
-Ideally, a test should leave the world exactly as it found it. But you often need to make some changes in order exercise every part of your code:
+Ideally, a test should leave the world exactly as it found it. But you often need to make some changes in order to exercise every part of your code:
 
 -   Create a file or directory
 -   Create a resource on an external system

vignettes/test-fixtures.Rmd

@@ -100,7 +100,7 @@ You'll have to explicit ignore them with `supressMesssages()`, or if they're imp
 
 ### waldo
 
-Probably the the biggest day-to-day difference (and the biggest reason to upgrade!) is the use of [`waldo::compare()`](https://waldo.r-lib.org/reference/compare.html) inside of `expect_equal()` and `expect_identical()`.
+Probably the biggest day-to-day difference (and the biggest reason to upgrade!) is the use of [`waldo::compare()`](https://waldo.r-lib.org/reference/compare.html) inside of `expect_equal()` and `expect_identical()`.
 The goal of waldo is to find and concisely describe the difference between a pair of R objects, and it's designed specifically to help you figure out what's gone wrong in your unit tests.
 
 ```{r, error = TRUE}