fix typos

Author: webistomin

src/composition-api.md

@@ -120,8 +120,8 @@ Again, entirely uninteresting - we `trigger` the click event, and assert that th
 
 ## Conclusion
 
-The article demonstrates how testing a component using the Composition API is identical to testing one using the traditional options API. The ideas and concepts are the same. The main point to be learned is when writing tests, make asserions based on inputs and outputs. 
+The article demonstrates how testing a component using the Composition API is identical to testing one using the traditional options API. The ideas and concepts are the same. The main point to be learned is when writing tests, make assertions based on inputs and outputs. 
 
-It should be possible to refactor any traditional Vue component to use the Composition API without the need to change the unit tests. If you find yourself needing to change your tests when refactoring, you are likely testing the *implmentation*, not the output. 
+It should be possible to refactor any traditional Vue component to use the Composition API without the need to change the unit tests. If you find yourself needing to change your tests when refactoring, you are likely testing the *implementation*, not the output. 
 
 While an exciting new feature, the Composition API is entirely additive, so there is no immediate need to use it, however regardless of your choice, remember a good unit tests asserts the final state of the component, without considering the implementation details.

src/finding-elements-and-components.md

@@ -6,7 +6,7 @@ Find the Vue.js 3 version [here](/v3/).
 
 `vue-test-utils` provides a number of ways to find and assert the presence of html elements or other Vue components using the `find` and `findComponent` methods. The main use of `find` is asserting a component correctly renders an element or child component.
 
-> Note: If you used Vue Test Utils prior to v1, you may remember `find` working with components as well as DOM elements. Now you use `find` and `findAll` for DOM elements, and `findComponent` and `findAllComponents` for Vue components. Ther is also a `get` and `getComponent` pair, which are exactly the same as `find` and `findComponent`, but they will raise an error if they do not find anything. This guide chooses to use `find` and `findComponent`.
+> Note: If you used Vue Test Utils prior to v1, you may remember `find` working with components as well as DOM elements. Now you use `find` and `findAll` for DOM elements, and `findComponent` and `findAllComponents` for Vue components. There is also a `get` and `getComponent` pair, which are exactly the same as `find` and `findComponent`, but they will raise an error if they do not find anything. This guide chooses to use `find` and `findComponent`.
 
 The source code for the test described on this page can be found [here](https://github.com/lmiller1990/vue-testing-handbook/tree/master/demo-app/tests/unit/Parent.spec.js).
 

src/simulating-user-input.md

@@ -277,7 +277,7 @@ In this section, we saw how to:
 
 - use `trigger` on events, even ones that use modifiers like `prevent`
 - use `setValue` to set a value of an `<input>` using `v-model`
-- use `await` with `trigger` and `setValue` to `await Vue.nextTick` ane ensure the DOM has updated
+- use `await` with `trigger` and `setValue` to `await Vue.nextTick` and ensure the DOM has updated
 - write tests using the three steps of unit testing
 - mock a method attached to `Vue.prototype` using the `mocks` mounting option
 - how to use `flush-promises` to immediately resolve all promises, a useful technique in unit testing

src/v3/composition-api.md

@@ -112,8 +112,8 @@ Again, entirely uninteresting - we `trigger` the click event, and assert that th
 
 ## Conclusion
 
-The article demonstrates how testing a component using the Composition API is identical to testing one using the traditional options API. The ideas and concepts are the same. The main point to be learned is when writing tests, make asserions based on inputs and outputs. 
+The article demonstrates how testing a component using the Composition API is identical to testing one using the traditional options API. The ideas and concepts are the same. The main point to be learned is when writing tests, make assertions based on inputs and outputs. 
 
-It should be possible to refactor any traditional Vue component to use the Composition API without the need to change the unit tests. If you find yourself needing to change your tests when refactoring, you are likely testing the *implmentation*, not the output. 
+It should be possible to refactor any traditional Vue component to use the Composition API without the need to change the unit tests. If you find yourself needing to change your tests when refactoring, you are likely testing the *implementation*, not the output. 
 
 While an exciting new feature, the Composition API is entirely additive, so there is no immediate need to use it, however regardless of your choice, remember a good unit tests asserts the final state of the component, without considering the implementation details.

src/v3/finding-elements-and-components.md

@@ -6,7 +6,7 @@ Find the Vue.js 2 version [here](/).
 
 `vue-test-utils` provides a number of ways to find and assert the presence of html elements or other Vue components using the `find` and `findComponent` methods. The main use of `find` is asserting a component correctly renders an element or child component.
 
-> Note: If you used Vue Test Utils prior to v1, you may remember `find` working with components as well as DOM elements. Now you use `find` and `findAll` for DOM elements, and `findComponent` and `findAllComponents` for Vue components. Ther is also a `get` and `getComponent` pair, which are exactly the same as `find` and `findComponent`, but they will raise an error if they do not find anything. This guide chooses to use `find` and `findComponent`.
+> Note: If you used Vue Test Utils prior to v1, you may remember `find` working with components as well as DOM elements. Now you use `find` and `findAll` for DOM elements, and `findComponent` and `findAllComponents` for Vue components. There is also a `get` and `getComponent` pair, which are exactly the same as `find` and `findComponent`, but they will raise an error if they do not find anything. This guide chooses to use `find` and `findComponent`.
 
 The source code for the test described on this page can be found [here](https://github.com/lmiller1990/vue-testing-handbook/tree/master/demo-app-vue-3/tests/unit/Parent.spec.js).
 

src/v3/simulating-user-input.md

@@ -281,7 +281,7 @@ In this section, we saw how to:
 
 - use `trigger` on events, even ones that use modifiers like `prevent`
 - use `setValue` to set a value of an `<input>` using `v-model`
-- use `await` with `trigger` and `setValue` to `await Vue.nextTick` ane ensure the DOM has updated
+- use `await` with `trigger` and `setValue` to `await Vue.nextTick` and ensure the DOM has updated
 - write tests using the three steps of unit testing
 - mock a method attached to `Vue.prototype` using the `global.mocks` mounting option
 - how to use `flush-promises` to immediately resolve all promises, a useful technique in unit testing

src/v3/vue-router.md

@@ -127,7 +127,7 @@ Finally, note we are using `mount`. If we use `shallowMount`, `<router-link>` wi
 
 Using `mount` is fine in some cases, but sometimes it is not ideal. For example, if you are rendering your entire `<App>` component, chances are the render tree is large, containing many components with their own children components and so on. A lot of children components will trigger various lifecycle hooks, making API requests and the such.
 
-If you are using Jest, its powerful mocking system provides an elegent solution to this problem. You can simply mock the child components, in this case `<NestedRoute>`. The following mock can be used and the above test will still pass:
+If you are using Jest, its powerful mocking system provides an elegant solution to this problem. You can simply mock the child components, in this case `<NestedRoute>`. The following mock can be used and the above test will still pass:
 
 ```js
 jest.mock("@/components/NestedRoute.vue", () => ({
@@ -222,7 +222,7 @@ Vue Router provides several types of router hooks, called ["navigation guards"](
 1. Global guards (`router.beforeEach`). Declared on the router instance.
 2. In component guards, such as `beforeRouteEnter`. Declared in components.
 
-Making sure these behave correctly is usually a job for an integration test, since you need to have a user navigate from one route to another. However, you can also use unit tests to see if the functions called in the navigation guards are working correctly and get faster feedback about potential bugs. Here are some strategies on decoupling logic from nagivation guards, and writing unit tests around them.
+Making sure these behave correctly is usually a job for an integration test, since you need to have a user navigate from one route to another. However, you can also use unit tests to see if the functions called in the navigation guards are working correctly and get faster feedback about potential bugs. Here are some strategies on decoupling logic from navigation guards, and writing unit tests around them.
 
 ## Global Guards
 

src/v3/vuex-actions.md

@@ -13,7 +13,7 @@ The source code for the test described on this page can be found [here](https://
 We will write an action that follows a common Vuex pattern:
 
 1. make an asynchronous call to an API
-2. do some proccessing on the data (optional)
+2. do some processing on the data (optional)
 3. commit a mutation with the result as the payload
 
 This is an `authenticate` action, which sends a username and password to an external API to check if they are a match. The result is then used to update the state by committing a `SET_AUTHENTICATED` mutation with the result as the payload.

src/v3/vuex-in-components.md

@@ -172,7 +172,7 @@ Now all the required data is contained in the test. Great! I like this. The test
 
 ## The `mapState` and `mapGetters` helper
 
-The above techniques all work in conjuction with Vuex's `mapState` and `mapGetters` helpers. We can update `ComponentWithGetters` to the following:
+The above techniques all work in conjunction with Vuex's `mapState` and `mapGetters` helpers. We can update `ComponentWithGetters` to the following:
 
 ```js
 import { mapGetters } from "vuex"
@@ -198,6 +198,6 @@ This guide discussed:
 - how to test `$store.state` and `getters`
 - using the `global.mocks` mounting option to mock `$store.state` and `getters`
 
-Techniques to test the implentation of Vuex getters in isolation can be found in [this guide](https://lmiller1990.github.io/vue-testing-handbook/vuex-getters.html).
+Techniques to test the implementation of Vuex getters in isolation can be found in [this guide](https://lmiller1990.github.io/vue-testing-handbook/vuex-getters.html).
 
 The source code for the test described on this page can be found [here](https://github.com/lmiller1990/vue-testing-handbook/tree/master/demo-app-vue-3/tests/unit/ComponentWithVuex.spec.js).

src/vue-router.md

@@ -72,7 +72,7 @@ Vue.use(VueRouter)
 export default new VueRouter({ routes })
 ```
 
-Since we do not want to polluate the global namespace by calling `Vue.use(...)` in our tests, we will create the router on a test by test basis. This will let us have more fine grained control over the state of the application during the unit tests.
+Since we do not want to pollute the global namespace by calling `Vue.use(...)` in our tests, we will create the router on a test by test basis. This will let us have more fine-grained control over the state of the application during the unit tests.
 
 ## Writing the Test
 
@@ -173,7 +173,7 @@ Another notable point that is different from other guides in this book is we are
 
 Using `mount` is fine in some cases, but sometimes it is not ideal. For example, if you are rendering your entire `<App>` component, chances are the render tree is large, containing many components with their own children components and so on. A lot of children components will trigger various lifecycle hooks, making API requests and the such.
 
-If you are using Jest, its powerful mocking system provides an elegent solution to this problem. You can simply mock the child components, in this case `<NestedRoute>`. The following mock can be used and the above test will still pass:
+If you are using Jest, its powerful mocking system provides an elegant solution to this problem. You can simply mock the child components, in this case `<NestedRoute>`. The following mock can be used and the above test will still pass:
 
 ```js
 jest.mock("@/components/NestedRoute.vue", () => ({
@@ -266,7 +266,7 @@ Vue Router provides several types of router hooks, called ["navigation guards"](
 1. Global guards (`router.beforeEach`). Declared on the router instance.
 2. In component guards, such as `beforeRouteEnter`. Declared in components.
 
-Making sure these behave correctly is usually a job for an integration test, since you need to have a user navigate from one route to another. However, you can also use unit tests to see if the functions called in the navigation guards are working correctly and get faster feedback about potential bugs. Here are some strategies on decoupling logic from nagivation guards, and writing unit tests around them.
+Making sure these behave correctly is usually a job for an integration test, since you need to have a user navigate from one route to another. However, you can also use unit tests to see if the functions called in the navigation guards are working correctly and get faster feedback about potential bugs. Here are some strategies on decoupling logic from navigation guards, and writing unit tests around them.
 
 ## Global Guards
 

src/vuex-actions.md

@@ -13,7 +13,7 @@ The source code for the test described on this page can be found [here](https://
 We will write an action that follows a common Vuex pattern:
 
 1. make an asynchronous call to an API
-2. do some proccessing on the data (optional)
+2. do some processing on the data (optional)
 3. commit a mutation with the result as the payload
 
 This is an `authenticate` action, which sends a username and password to an external API to check if they are a match. The result is then used to update the state by committing a `SET_AUTHENTICATED` mutation with the result as the payload.

src/vuex-in-components.md

@@ -132,7 +132,7 @@ it("renders a username using a real Vuex getter", () => {
 })
 ```
 
-The test is very compact - just two lines of code. There is a lot of setup involved, however - we are bascially rebuilding the Vuex store. An alternative is to import the real Vuex store, with the actual getter. This introduces another dependency to the test though, and when developing a large system, it's possible the Vuex store might be being developed by another programmer, and has not been implemented yet. 
+The test is very compact - just two lines of code. There is a lot of setup involved, however - we are basically rebuilding the Vuex store. An alternative is to import the real Vuex store, with the actual getter. This introduces another dependency to the test though, and when developing a large system, it's possible the Vuex store might be being developed by another programmer, and has not been implemented yet. 
 
 Let's see how we can write the test using the `mocks` mounting option:
 
@@ -176,7 +176,7 @@ This is more concise than the two previous tests, and still expresses the compon
 
 ## The `mapState` and `mapGetters` helper
 
-The above techniques all work in conjuction with Vuex's `mapState` and `mapGetters` helpers. We can update `ComponentWithGetters` to the following:
+The above techniques all work in conjunction with Vuex's `mapState` and `mapGetters` helpers. We can update `ComponentWithGetters` to the following:
 
 ```js
 import { mapGetters } from "vuex"
@@ -202,6 +202,6 @@ This guide discussed:
 - using the `mocks` mounting option to mock `$store.state` and `getters`
 - using the `computed` mounting option to set the desired value of a Vuex getter
 
-Techniques to test the implentation of Vuex getters in isolation can be found in [this guide](https://lmiller1990.github.io/vue-testing-handbook/vuex-getters.html).
+Techniques to test the implementation of Vuex getters in isolation can be found in [this guide](https://lmiller1990.github.io/vue-testing-handbook/vuex-getters.html).
 
 The source code for the test described on this page can be found [here](https://github.com/lmiller1990/vue-testing-handbook/tree/master/demo-app/tests/unit/ComponentWithVuex.spec.js).