docs: more improvements (vuejs#94)

Author: kazupon

docs/en/README.md

@@ -8,7 +8,7 @@
   * [Choosing a test runner](guides/choosing-a-test-runner.md)
   * [Testing SFCs with Jest](guides/testing-SFCs-with-jest.md)
   * [Testing SFCs with Mocha + webpack](guides/testing-SFCs-with-mocha-webpack.md)
-  * [Using with Vue Router](guides/using-with-router.md)
+  * [Using with Vue Router](guides/using-with-vue-router.md)
   * [Using with Vuex](guides/using-with-vuex.md)
 * [API](api/README.md)
   * [createLocalVue](api/createLocalVue.md)

docs/en/SUMMARY.md

@@ -6,7 +6,7 @@
   * [Choosing a test runner](guides/choosing-a-test-runner.md)
   * [Testing SFCs with Jest](guides/testing-SFCs-with-jest.md)
   * [Testing SFCs with Mocha + webpack](guides/testing-SFCs-with-mocha-webpack.md)
-  * [Using with Vue Router](guides/using-with-router.md)
+  * [Using with Vue Router](guides/using-with-vue-router.md)
   * [Using with Vuex](guides/using-with-vuex.md)
 * [API](api/README.md)
   * [mount](api/mount.md)

docs/en/guides/using-with-vue-router.md

@@ -1,10 +1,10 @@
-# Using with vue-router
+# Using with Vue Router
 
-## Installing vue-router in tests
+## Installing Vue Router in tests
 
-You should never install vue-router on the Vue base constructor in tests. Installing vue-router adds `$route` and `$router` as read-only properties on Vue prototype.
+You should never install Vue Router on the Vue base constructor in tests. Installing Vue Router adds `$route` and `$router` as read-only properties on Vue prototype.
 
-To avoid this, we can create a localVue, and install vue-router on that.
+To avoid this, we can create a localVue, and install Vue Router on that.
 
 ```js
 import VueRouter from 'vue-router'
@@ -17,9 +17,9 @@ shallow(Component, {
 })
 ```
 
-## Testing components that use router-link or router-view
+## Testing components that use `router-link` or `router-view`
 
-When you install vue-router, the router-link and router-view components are registered. This means we can use them anywhere in our application without needing to import them.
+When you install Vue Router, the `router-link` and `router-view` components are registered. This means we can use them anywhere in our application without needing to import them.
 
 When we run tests, we need to make these vue-router components available to the component we're mounting. There are two methods to do this.
 
@@ -31,7 +31,7 @@ shallow(Component, {
 })
 ```
 
-### Installing vue-router with localVue
+### Installing Vue Router with localVue
 
 ```js
 import VueRouter from 'vue-router'
@@ -44,7 +44,7 @@ shallow(Component, {
 })
 ```
 
-## Mocking $route and $router
+## Mocking `$route` and `$router`
 
 Sometimes you want to test that a component does something with parameters from the `$route` and `$router` objects. To do that, you can pass custom mocks to the Vue instance.
 
@@ -64,8 +64,8 @@ wrapper.vm.$router // /some/path
 
 ## Common gotchas
 
-Installing vue-router adds `$route` and `$router` as read-only properties on Vue prototype.
+Installing Vue Router adds `$route` and `$router` as read-only properties on Vue prototype.
 
-This means any future tests that try to mock $route or `$router` will fail.
+This means any future tests that try to mock `$route` or `$router` will fail.
 
-To avoid this, never install vue-router when you're running tests.
+To avoid this, never install Vue Router when you're running tests.

docs/en/guides/using-with-vuex.md

@@ -1,6 +1,6 @@
 # Using with Vuex
 
-In this guide, we'll see how to test Vuex in components with vue-test-utils.
+In this guide, we'll see how to test Vuex in components with `vue-test-utils`.
 
 ## Mocking Actions
 
@@ -91,17 +91,17 @@ describe('Actions.vue', () => {
 })
 ```
 
-What’s happening here? First we tell Vue to use Vuex with the Vue.use method. This is just a wrapper around Vue.use.
+What’s happening here? First we tell Vue to use Vuex with the `Vue.use` method. This is just a wrapper around `Vue.use`.
 
-We then make a mock store by calling new Vuex.store with our mock values. We only pass it the actions, since that’s all we care about.
+We then make a mock store by calling new `Vuex.store` with our mock values. We only pass it the actions, since that’s all we care about.
 
 The actions are [jest mock functions](https://facebook.github.io/jest/docs/en/mock-functions.html). These mock functions give us methods to assert whether the actions were called or not.
 
 We can then assert in our tests that the action stub was called when expected.
 
 Now the way we define the store might look a bit foreign to you.
 
-We’re using beforeEach to ensure we have a clean store before each test. beforeEach is a mocha hook that’s called before each test. In our test, we are reassigning the store variables value. If we didn’t do this, the mock functions would need to be automatically reset. It also lets us change the state in our tests, without it affecting later tests.
+We’re using `beforeEach` to ensure we have a clean store before each test. `beforeEach` is a mocha hook that’s called before each test. In our test, we are reassigning the store variables value. If we didn’t do this, the mock functions would need to be automatically reset. It also lets us change the state in our tests, without it affecting later tests.
 
 The most important thing to note in this test is that **we create a mock Vuex store and then pass it to vue-test-utils**.
 
@@ -130,7 +130,7 @@ export default{
 </script>
 ```
 
-This is a fairly simple component. It renders the result of the getters clicks and inputValue. Again, we don’t really care about what those getters returns – just that the result of them is being rendered correctly.
+This is a fairly simple component. It renders the result of the getters `clicks` and `inputValue`. Again, we don’t really care about what those getters returns – just that the result of them is being rendered correctly.
 
 Let’s see the test:
 
@@ -171,7 +171,7 @@ describe('Getters.vue', () => {
   })
 })
 ```
-This test is similar to our actions test. We create a mock store before each test, pass it as an option when we call shallow, and assert that the value returned by our mock getters is being rendered.
+This test is similar to our actions test. We create a mock store before each test, pass it as an option when we call `shallow`, and assert that the value returned by our mock getters is being rendered.
 
 This is great, but what if we want to check our getters are returning the correct part of our state?