Merge pull request volksbright#212 from veaba/2.0-cn

完成了Vuex testing.md翻译

Author: dingyiming

src/vuex/testing.md

@@ -3,17 +3,15 @@ title: 测试
 type: vuex
 order: 13
 ---
+我们主要针对Vuex中的mutaions 和actions进行单元测试。
 
-The main parts we want to unit test in Vuex are mutations and actions.
+### 测试 Mutations
 
-### Testing Mutations
-
-Mutations are very straightforward to test, because they are just functions that completely rely on their arguments. One trick is that if you are using ES2015 modules and put your mutations inside your `store.js` file, in addition to the default export, you can also export the mutations as a named export:
+Mutations 很容易被测试，因为它们仅仅是一些完全依赖参数的函数。小技巧是，如果你在 `store.js` 文件中定义了 mutations，并且使用 ES2015 模块功能默认输出，那么你仍然可以给 mutations 取个变量名然后把它输出去：
 
 ``` js
 const state = { ... }
-
-// export mutations as a named export
+//取个变量名并输出mutations
 export const mutations = { ... }
 
 export default new Vuex.Store({
@@ -22,7 +20,7 @@ export default new Vuex.Store({
 })
 ```
 
-Example testing a mutation using Mocha + Chai (you can use any framework/assertion libraries you like):
+以下为使用 Mocha + chai 测试 mutation 的例子（实际上你可以用任何你喜欢测试框架）
 
 ``` js
 // mutations.js
@@ -36,7 +34,7 @@ export const mutations = {
 import { expect } from 'chai'
 import { mutations } from './store'
 
-// destructure assign mutations
+// 解构赋值mutations（destructure assign mutations）
 const { increment } = mutations
 
 describe('mutations', () => {
@@ -51,11 +49,14 @@ describe('mutations', () => {
 })
 ```
 
-### Testing Actions
+### 测试 Actions
+
+
+Actions 可能会更加棘手一些，因为他们可能要求请求外部API.
 
-Actions can be a bit more tricky because they may call out to external APIs. When testing actions, we usually need to do some level of mocking - for example, we can abstract the API calls into a service and mock that service inside our tests. In order to easily mock dependencies, we can use Webpack and [inject-loader](https://github.com/plasticine/inject-loader) to bundle our test files.
+当测试actions时，我们通常需要增加mocking服务层——例如，我们可以把API调用抽象成服务，然后我们在测试中模拟这种服务。为了便于解决mock的依赖关系，可以用 Webpack 和 [inject-loader](https://github.com/plasticine/inject-loader) 打包测试文件。
 
-Example testing an async action:
+异步action测试示例：
 
 ``` js
 // actions.js
@@ -71,14 +72,13 @@ export const getAllProducts = ({ dispatch }) => {
 
 ``` js
 // actions.spec.js
-
-// use require syntax for inline loaders.
-// with inject-loader, this returns a module factory
-// that allows us to inject mocked dependencies.
+// 使用 require 语法处理内联loaders
+//inject-loader,返回一个模块工厂
+//让我们能够注入mocked的依赖关系。
 import { expect } from 'chai'
 const actionsInjector = require('inject!./actions')
 
-// create the module with our mocks
+//使用mocks创建模块
 const actions = actionsInjector({
   '../api/shop': {
     getProducts (cb) {
@@ -89,11 +89,11 @@ const actions = actionsInjector({
   }
 })
 
-// helper for testing action with expected mutations
+//用指定的mutatios测试action的辅助函数
 const testAction = (action, args, state, expectedMutations, done) => {
   let count = 0
 
-  // mock commit
+  // mock 提交
   const commit = (type, payload) => {
     const mutation = expectedMutations[count]
     expect(mutation.type).to.equal(type)
@@ -106,10 +106,10 @@ const testAction = (action, args, state, expectedMutations, done) => {
     }
   }
 
-  // call the action with mocked store and arguments
+  // 用模拟的 store 和参数调用 action
   action({ commit, state }, ...args)
 
-  // check if no mutations should have been dispatched
+  // 检查是否没有 mutation 被 dispatch
   if (expectedMutations.length === 0) {
     expect(count).to.equal(0)
     done()
@@ -126,11 +126,11 @@ describe('actions', () => {
 })
 ```
 
-### Testing Getters
+### 测试 Getters
 
-If your getters have complicated computation, it is worth testing them. Getters are also very straightforward to test as same reason as mutations.
+如果你的getters方法很复杂，那么你得测试他们。测试Getter 方法和测试mutations一样非常简单！
 
-Example testing a getter:
+测试getter实例：
 
 ``` js
 // getters.js
@@ -150,7 +150,7 @@ import { getters } from './getters'
 
 describe('getters', () => {
   it('filteredProducts', () => {
-    // mock state
+    // mock 状态
     const state = {
       products: [
         { id: 1, title: 'Apple', category: 'fruit' },
@@ -161,10 +161,10 @@ describe('getters', () => {
     // mock getter
     const filterCategory = 'fruit'
 
-    // get the result from the getter
+    // 从getter中取回值
     const result = getters.filteredProducts(state, { filterCategory })
 
-    // assert the result
+    // 声明返回值
     expect(result).to.deep.equal([
       { id: 1, title: 'Apple', category: 'fruit' },
       { id: 2, title: 'Orange', category: 'fruit' }
@@ -173,13 +173,14 @@ describe('getters', () => {
 })
 ```
 
-### Running Tests
+### 运行测试
+
+如果你的 mutations 和 actions 已经正确，后面应该在适合的mocking上浏览器测试API的依赖关系。
 
-If your mutations and actions are written properly, the tests should have no direct dependency on Browser APIs after proper mocking. Thus you can simply bundle the tests with Webpack and run it directly in Node. Alternatively, you can use `mocha-loader` or Karma + `karma-webpack` to run the tests in real browsers.
+#### 在Node上运行
 
-#### Running in Node
+创建下面的webpack配置（加上适合[`.babelrc`](https://babeljs.io/docs/usage/babelrc/)）：
 
-Create the following webpack config (together with proper [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
 
 ``` js
 // webpack.config.js
@@ -201,20 +202,20 @@ module.exports = {
 }
 ```
 
-Then:
+然后:
 
 ``` bash
 webpack
 mocha test-bundle.js
 ```
 
-#### Running in Browser
+#### 在浏览器上运行
 
-1. Install `mocha-loader`
-2. Change the `entry` from the Webpack config above to `'mocha!babel!./test.js'`.
-3. Start `webpack-dev-server` using the config
-4. Go to `localhost:8080/webpack-dev-server/test-bundle`.
+1. 安装 `mocha-loader`
+2. 把上述 webpack 配置中的 entry 改成 'mocha!babel!./test.js'
+3. 用以上配置启动 `webpack-dev-server` 
+4. 访问 `localhost:8080/webpack-dev-server/test-bundle`.
 
-#### Running in Browser with Karma + karma-webpack
+#### 使用Karma + karma-webpack在浏览器中测试
 
-Consult the setup in [vue-loader documentation](http://vue-loader.vuejs.org/en/workflow/testing.html).
+详细的安装咨询见[vue-loader documentation](http://vue-loader.vuejs.org/en/workflow/testing.html).