feat(overmind): improve testing approach

Author: christianalfoni

packages/node_modules/overmind/src/index.ts

@@ -78,19 +78,11 @@ function deepCopy(obj) {
 
 export function createMock<Config extends Configuration>(
   config: Config,
-  effectsCallback?: (
-    effect: {
-      path: string
-      args: any[]
-    },
-    index: number
-  ) => any
+  mockedEffects?: Partial<Config['effects']>
 ): {
   actions: ResolveMockActions<Config['actions']>
   state: ResolveState<Config['state']>
 } {
-  let effectCount = 0
-  let effectsCalled = []
   const mock = new Overmind(
     Object.assign({}, config, {
       state: deepCopy(config.state),
@@ -99,28 +91,25 @@ export function createMock<Config extends Configuration>(
       devtools: false,
       testMode: {
         effectsCallback: (effect) => {
-          if (!effectsCallback) {
-            return
+          const mockedEffect = (effect.name
+            ? effect.name.split('.')
+            : []
+          ).reduce((aggr, key) => (aggr ? aggr[key] : aggr), mockedEffects)
+
+          if (!mockedEffect || (mockedEffect && !mockedEffect[effect.method])) {
+            throw new Error(
+              `The effect "${effect.name}" with metod ${
+                effect.method
+              } has not been mocked`
+            )
           }
-
-          return effectsCallback(
-            {
-              path: effect.name + '.' + effect.method,
-              args: effect.args,
-            },
-            effectCount++
-          )
+          return mockedEffect[effect.method]({
+            path: effect.name + '.' + effect.method,
+            args: effect.args,
+          })
         },
         actionCallback: (execution) => {
-          const effects = effectsCalled.slice()
-
-          effectCount = 0
-          effectsCalled.length = 0
-
-          return {
-            mutations: execution.flush().mutations,
-            effects,
-          }
+          return execution.flush().mutations
         },
       },
     }

packages/node_modules/overmind/src/internalTypes.ts

@@ -200,13 +200,7 @@ type NestedMockActions =
     }
   | undefined
 
-type MockResult = {
-  mutations: IMutation[]
-  effects: ({
-    path: string
-    args: any[]
-  })[]
-}
+type MockResult = IMutation[]
 
 export type ResolveMockActions<
   Actions extends NestedMockActions

packages/node_modules/overmind/src/mock.test.ts

@@ -13,35 +13,40 @@ describe('Mock', () => {
     const state: State = {
       foo: 'bar',
     }
-    const test: Action = ({ state }) => {
-      state.foo = 'bar2'
+    const test: Action = ({ state, effect }) => {
+      state.foo = effect()
     }
     const actions = { test }
+    const effect = () => 'bar2'
+    const effects = { effect }
     const config = {
       state,
       actions,
+      effects,
     }
 
     type Config = {
       state: typeof state
       actions: typeof actions
+      effects: typeof effects
     }
 
     type Action<Input = void> = TAction<Config, Input>
 
-    const mock = createMock(config)
+    const mock = createMock(config, {
+      effect() {
+        return 'bar3'
+      },
+    })
 
     return mock.actions.test().then((result) =>
-      expect(result).toEqual({
-        mutations: [
-          {
-            method: 'set',
-            path: 'foo',
-            args: ['bar2'],
-          },
-        ],
-        effects: [],
-      })
+      expect(result).toEqual([
+        {
+          method: 'set',
+          path: 'foo',
+          args: ['bar3'],
+        },
+      ])
     )
   })
 })

packages/overmind-website/examples/guide/writingtests/actionsnapshot.ts

@@ -0,0 +1,42 @@
+export default () => [
+  {
+    fileName: 'overmind/actions.test.ts',
+    code: `
+import { createMock } from 'overmind'
+import { config } from './'
+
+describe('Actions', () => {
+  describe('getPost', () => {
+    test('should get post with passed id', async () => {
+      const mock = createMock(config, {
+        api: {
+          getPost(id) {
+            return Promise.resolve({
+              id
+            })
+          }
+        }
+      })
+
+      const mutations = await actions.getPost('1')
+
+      expect(mutations).toMatchSnapshot()
+    })
+    test('should handle errors', async () => {
+      const mock = createMock(config, {
+        api = {
+          getPost() {
+            throw new Error('test')
+          }
+        }
+      })
+
+      const mutations = await actions.getPost('1')
+
+      expect(mutations).toMatchSnapshot()
+    })
+  })
+})
+    `,
+  },
+]

packages/overmind-website/examples/guide/writingtests/actiontest.ts

@@ -2,37 +2,43 @@ export default () => [
   {
     fileName: 'overmind/actions.test.ts',
     code: `
-import * as actions from './actions'
+import { createMock } from 'overmind'
+import { config } from './'
 
 describe('Actions', () => {
   describe('getPost', () => {
     test('should get post with passed id', async () => {
-      const state = {}
-      const api = {
-        getPost(id) {
-          return Promise.resolve({
-            id
-          })
+      const mock = createMock(config, {
+        api: {
+          getPost(id) {
+            return Promise.resolve({
+              id
+            })
+          }
         }
-      }
+      })
 
       await actions.getPost('1')
 
-      expect(state.isLoadingPost).toBe(false)
-      expect(state.currentPost).toEqual({ id: '1' })
+      expect(mock.state).toEqual({
+        isLoadingPost: false,
+        currentPost: { id: '1' },
+        error: null
+      })
     })
     test('should handle errors', async () => {
-      const state = {}
-      const api = {
-        getPost() {
-          throw new Error('test')
+      const mock = createMock(config, {
+        api = {
+          getPost() {
+            throw new Error('test')
+          }
         }
-      }
+      })
 
       await actions.getPost('1')
 
-      expect(state.isLoadingPost).toBe(false)
-      expect(state.error.message).toBe('test')
+      expect(mock.state.isLoadingPost).toBe(false)
+      expect(mock.state.error.message).toBe('test')
     })
   })
 })

packages/overmind-website/examples/guide/writingtests/effecttest.ts

@@ -2,13 +2,13 @@ export default () => [
   {
     fileName: 'overmind/effects.test.ts',
     code: `
-import * as effects from './effects'
+import { Api } from './effects'
 
 describe('Effects', () => {
   describe('Api', () => {
-    test('should get a post', async () => {
+    test('should get a post using baseUrl and authToken in header', async () => {
       expect.assertions(3)
-      const api = new effects.Api({
+      const api = new Api({
         get(url, config) {
           expect(url).toBe('/test/posts/1')
           expect(config).toEqual({

packages/overmind-website/guides/intermediate/05_writingtests.md

@@ -1,10 +1,10 @@
 # Writing tests
 
-Testing is a broad subject and everybody has an opinion about it. We can only show you how we think about testing in general and how to effectively write those tests for your Overmind app. The benefit of Overmind is that you only test pure functions. That means there is no trickery to testing actions or operators. Your effects can also easily be made testable. These kinds of tests is what you would call **unit tests**. Since these unit tests covers the intention of each piece of logic we do not consider any need for writing integration tests on the logic. If you want to test how your application works when it is all put together we recommend doing integration tests as close to the user experience as possible. Testing solutions like [Cypress.io](https://www.cypress.io/) is a great way to do integration tests as close to the user experience as possible.
+Testing is a broad subject and everybody has an opinion on it. We can only show you how we think about testing in general and how to effectively write those tests for your Overmind app. It is encouraged to think **unit testing** of actions and effects. This will cover expected changes in state and that your side effects behaves in a predictable manner. If you want to test how your application works when it is all put together we recommend doing integration tests as close to the user experience as possible. Testing solutions like [Cypress.io](https://www.cypress.io/) is a great way to do exactly that.
 
 ## Testing actions
 
-Since all effects are "injected" into actions you can easily stub them out. That means if you for example have an action that looks like this:
+When testing an action you want to verify that changes to state are performed as expected. To give you the best possible testing experience Overmind has mocking tool called **createMock**. It takes your application configuration and allows you to run actions as if they were run from components.
 
 ```marksy
 h(Example, { name: "guide/writingtests/action.ts" })
@@ -18,23 +18,13 @@ h(Example, { name: "guide/writingtests/actiontest.ts" })
 
 If your actions can result in multiple scenarios a unit test is beneficial. But you will be surprised how straight forward the logic of your actions will become. Since effects are encouraged to be application specific you will most likely be testing those more than you will test any action.
 
-## Testing operators
-
-Operators are based on the [op-op specification](https://github.com/christianalfoni/op-op-spec), which means that they actually have a different signature when being called. This is not something you think about writing your application code, but when testing single operators it is important to get it right.
-
-So imagine you have an operator like:
-
-```marksy
-h(Example, { name: "guide/writingtests/operator.ts" })
-```
-
-You might want to test that it does what you want it to:
+You do not have to explicitly write the expected state. You can also use for example [jest]() for snapshot testing. The action will return a list of mutations performed and effects run. This is perfect for snapshot testing.
 
 ```marksy
-h(Example, { name: "guide/writingtests/operatortest.ts" })
+h(Example, { name: "guide/writingtests/actionsnapshot.ts" })
 ```
 
-You can even do tests of pipes that are composed of multiple operators. You just pass in a stubbed context and check it on the *complete* callback (the second one).
+In this scenario we would also ensure that the **isLoadingPost** state indeed flipped to *true* before moving to *false* at the end.
 
 ## Testing effects