padcom
diff --git a/‎docs/en/getters.md
Lines changed: 18 additions & 3 deletions b/‎docs/en/getters.md
Lines changed: 18 additions & 3 deletions
diff --git a/‎docs/en/modules.md
Lines changed: 13 additions & 0 deletions b/‎docs/en/modules.md
Lines changed: 13 additions & 0 deletions
diff --git a/‎docs/en/testing.md
Lines changed: 47 additions & 0 deletions
< 10000 /div> b/‎docs/en/testing.md
Lines changed: 47 additions & 0 deletions
< 10000 /div>
@@ -13,7 +13,7 @@ computed: {
 
 If more than one component needs to make use of this, we have to either duplicate the function, or extract it into a shared helper and import it in multiple places - both are less than ideal.
 
-Vuex allows us to define "getters" in the store (think of them as computed properties for stores):
+Vuex allows us to define "getters" in the store (think of them as computed properties for stores). Getters will receive the state as their 1st argument:
 
 ``` js
 const store = new Vuex.Store({
@@ -24,15 +24,30 @@ const store = new Vuex.Store({
     ]
   },
   getters: {
-    doneTodosCount: state => {
-      return state.todos.filter(todo => todo.done).length
+    doneTodos: state => {
+      return state.todos.filter(todo => todo.done)
     }
   }
 })
 ```
 
 The getters will be exposed on the `store.getters` object:
 
+``` js
+store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
+```
+
+Getters will also receive other getters as the 2nd argument:
+
+``` js
+getters: {
+  // ...
+  doneTodosCount: (state, getters) => {
+    return getters.doneTodos.length
+  }
+}
+```
+
 ``` js
 store.getters.doneTodosCount // -> 1
 ```
 
@@ -69,6 +69,19 @@ const moduleA = {
 }
 ```
 
+Also, inside module getters, the root state will be exposed as their 3rd argument:
+
+``` js
+const moduleA = {
+  // ...
+  getters: {
+    sumWithRootCount (state, getters, rootState) {
+      return state.count + rootState.count
+    }
+  }
+}
+```
+
 ### Namespacing
 
 Note that actions, mutations and getters inside modules are still registered under the **global namespace** - this allows multiple modules to react to the same mutation/action type. You can namespace the module assets yourself to avoid name clashing by prefixing or suffixing their names. And you probably should if you are writing a reusable Vuex module that will be used in unknown environments. For example, we want to create a `todos` module:
 
@@ -122,6 +122,53 @@ describe('actions', () => {
 })
 ```
 
+### Testing Getters
+
+If your getters have complicated computation, it is worth testing them. Getters are also very straightforward to test as same reason as mutations.
+
+Example testing a getter:
+
+``` js
+// getters.js
+export const getters = {
+  filteredProducts (state, { filterCategory }) {
+    return state.products.filter(product => {
+      return product.category === filterCategory
+    })
+  }
+}
+```
+
+``` js
+// getters.spec.js
+import { expect } from 'chai'
+import { getters } from './getters'
+
+describe('getters', () => {
+  it('filteredProducts', () => {
+    // mock state
+    const state = {
+      products: [
+        { id: 1, title: 'Apple', category: 'fruit' },
+        { id: 2, title: 'Orange', category: 'fruit' },
+        { id: 3, title: 'Carrot', category: 'vegetable' }
+      ]
+    }
+    // mock getter
+    const filterCategory = 'fruit'
+
+    // get the result from the 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' }
+    ])
+  })
+})
+```
+
 ### Running Tests
 
 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.