You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/README.md
+6-9Lines changed: 6 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,17 +88,14 @@ Read the following guides for different setups:
88
88
-[Testing SFCs with Jest](./guides/testing-SFCs-with-jest.md)
89
89
-[Testing SFCs with Mocha + webpack](./guides/testing-SFCs-with-mocha-webpack.md)
90
90
91
-
## Knowing what to test
91
+
###Knowing What to Test
92
92
93
-
It's difficult to generalize what you should test and what you shouldn't, because it's a trade-off that has to do with your development requirements and time constraints. However, there are some general rules you can follow.
93
+
For UI components, we don't recommend aiming for complete line-based coverage, because it leads to too much focus on the internal implementation details of the components and could result in brittle tests.
94
94
95
-
You should write tests to assert your component's logic, not implementation details. The best way to test the logic of component is to make sure an input (user interaction or change of props) creates the expected output.
95
+
Instead, we recommend writing tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events).
96
96
97
-
For example, imagine we have a `Counter` component that increments a display counter by 1 each time a button is clicked. The test should perform the click and assert that the counter increased by 1. This ensures that your test is not implementation specific. You can rewrite the logic of the test, and as long as clicking a button still updates the counter text, the test will pass.
97
+
For example, imagine we have a `Counter` component that increments a display counter by 1 each time a button is clicked. Its test case would simulate the click and assert that the rendered output has increased by 1. The test doesn't care about how the Counter increments the value, it only cares about the input and the output.
98
98
99
-
## Example projects
99
+
The benefit of this approach is that as long as your component's public interface remains the same, your tests will pass no matter how the component's internal implementation changes over time.
100
100
101
-
-[example with Jest](https://github.com/eddyerburgh/vue-test-utils-jest-example)
102
-
-[example with Mocha](https://github.com/eddyerburgh/vue-test-utils-mocha-example)
103
-
-[example with tape](https://github.com/eddyerburgh/vue-test-utils-tape-example)
104
-
-[example with AVA](https://github.com/eddyerburgh/vue-test-utils-ava-example)
101
+
This topic is discussed with more details in a [great presentation by Matt O'Connell](http://slides.com/mattoconnell/deck#/).
`vue-test-utils` relies on a browser environment. Technically you can run it in a real browser, but it's not recommended due to the complexity of launching real browsers on different platforms. Instead, we recommend running the tests in Node.js with a virtual browser environment using [JSDOM](https://github.com/tmpvar/jsdom).
6
+
7
+
The Jest test runner sets up JSDOM automatically. For other test runners, you can manually set up JSDOM for the tests using [jsdom-global](https://github.com/rstacruz/jsdom-global) in the entry for your tests:
8
+
9
+
```bash
10
+
npm install --save-dev jsdom jsdom-global
11
+
```
12
+
---
13
+
```js
14
+
// in test setup / entry
15
+
require('jsdom-global')()
16
+
```
17
+
18
+
## Testing Components that Rely on Global Plugins and Mixins
19
+
20
+
Some of the components may rely on features injected by a global plugin or mixin, for example `vuex` and `vue-router`.
21
+
22
+
If you are writing tests for components in a specific app, you can setup the same global plugins and mixins once in the entry of your tests. But in some cases, for example testing a generic component suite that may get shared across different apps, it's better to test your components in a more isolated setup, without polluting the global `Vue` constructor. We can use the [createLocalVue](../api/createLocalVue.md) method to achieve that:
Copy file name to clipboardExpand all lines: docs/en/guides/testing-SFCs-with-jest.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,13 +42,14 @@ We need to add a `.babelrc` file, to tell babel to use the env preset:
42
42
}
43
43
```
44
44
45
-
By default, Jest doesn't recognize .vue files. So we need to tell Jest how to handle them. To do that we need to install jest-vue, which preprocesses .vue files:
45
+
By default, Jest doesn't recognize `.vue` files. So we need to tell Jest how to handle them. To do that we need to install jest-vue, which preprocesses `.vue` files:
46
46
47
47
```
48
48
npm install --sav-dev jest-vue
49
49
```
50
50
51
51
In our `package.json`, we need to add a field to tell Jest how to treat .vue files:
Copy file name to clipboardExpand all lines: docs/en/guides/testing-SFCs-with-mocha-webpack.md
+23-32Lines changed: 23 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,44 +23,35 @@ Next we need to define a unit script in our `package.json`.
23
23
}
24
24
```
25
25
26
-
This script tells mocha-webpack to get the webpack config from build/webpack.conf.js, run all test files in the test directory and run test/setup.js before the tests.
26
+
This script tells `mocha-webpack` to get the webpack config from `build/webpack.conf.js`, run all test files in the test directory and run `test/setup.js` before the tests.
27
+
28
+
### Setting Up Browser Environment
27
29
28
30
Let's create the setup.js script first.
29
31
30
-
`vue-test-utils` requires a browser environment to run. We can set one up using browser-env (a wrapper around JSDOM).
32
+
`vue-test-utils` requires a browser environment to run. We can set one up using `jsdom-global`, which setups a JSDOM instance and attaches necessary globals to the Node process.
31
33
32
-
Let's install that:
34
+
Let's install the dependencies:
33
35
34
-
```
35
-
npm install --save-dev browser-env
36
+
```bash
37
+
npm install --save-dev jsdom jsdom-global
36
38
```
37
39
38
-
Create a test/setup.js file and paste the following code in:
40
+
Create a `test/setup.js` file and paste the following code in:
39
41
40
-
```
41
-
require('browser-env')();
42
+
```js
43
+
require('jsdom-global')()
42
44
```
43
45
44
46
This adds a browser environment to node, so that `vue-test-utils` can run correctly.
45
47
46
-
Next, we need to install babel and configure it so we can use ES6 features in our JavaScript:
Now we need to create a webpack config file. In most cases your test config should use the same `module` rules with your projects existing webpack config. We recommend extracting the common config options into a base file and extend it separately for build and testing.
51
51
52
-
and create a .babelrc file in the root of the project, that tells babel to use the env preset:
52
+
One specific tweak needed for the test config is that we should externalize Node dependencies with `webpack-node-externals`. This significantly speeds up the bundling process.
53
53
54
-
```json
55
-
// .babelrc
56
-
{
57
-
"presets": ["env"]
58
-
}
59
-
```
60
-
61
-
*babel-preset-env allows compiling the JS based on the browsers you plan to support. Get more info here: [babel-preset-env](https://github.com/babel/babel-preset-env)*
62
-
63
-
Now we need to create a webpack config file. Create a build/webpack.conf.js file, and add the following code:
54
+
For our example project, the config looks like this:
Notice that we are using `babel-loader` to handle JavaScript. You should already have Babel configured if you are using it in your app, e.g. via a `.babelrc` file. Here `babel-loader` will automatically use the same config file.
91
81
92
-
Create a file in src named Counter.vue.
82
+
One thing to note is that if you are using Node 6+, which already supports the majority of ES2015 features, you can configure a separate Babel [env option](https://babeljs.io/docs/usage/babelrc/#env-option) that only transpiles features that are not already supported in the Node version you are using (e.g. `stage-2` or flow syntax support, etc.)
93
83
94
-
Paste the following code in src/Counter.vue:
84
+
### Adding a test
95
85
86
+
Create a file in `src` named `Counter.vue`:
96
87
97
-
```vue
88
+
```html
98
89
<template>
99
90
<div>
100
91
{{ count }}
@@ -119,7 +110,7 @@ export default {
119
110
</script>
120
111
```
121
112
122
-
And create a test file—`test/Counter.spec.js`. Paste the code below into the file:
113
+
And create a test file named `test/Counter.spec.js` with the following code:
0 commit comments