Gathering detailed insights and metrics for vuex-mock-store
Gathering detailed insights and metrics for vuex-mock-store
Gathering detailed insights and metrics for vuex-mock-store
Gathering detailed insights and metrics for vuex-mock-store
npm install vuex-mock-store
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
272 Stars
286 Commits
19 Forks
3 Watching
2 Branches
8 Contributors
Updated on 18 Nov 2024
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
-11.9%
27,812
Compared to previous day
Last week
-12.2%
107,538
Compared to previous week
Last month
53.4%
482,303
Compared to previous month
Last year
127.7%
3,613,182
Compared to previous year
1
1
Simple and straightforward mock for Vuex v3.x and v4.x (Vue 2 and 3)
Automatically creates spies on commit
and dispatch
so you can focus on testing your component without executing your store code.
Help me keep working on Open Source in a sustainable way 🚀. Help me with as little as $1 a month, sponsor me on Github.
1npm install -D vuex-mock-store 2# with yarn 3yarn add -D vuex-mock-store
ℹ️: All examples use Jest API. See below to use a different mock library.
Usage with vue-test-utils:
Given a component MyComponent.vue
:
1<template> 2 <div> 3 <p class="count">{{ count }}</p> 4 <p class="doubleCount">{{ doubleCount }}</p> 5 <button class="increment" @click="increment">+</button> 6 <button class="decrement" @click="decrement">-</button> 7 <hr /> 8 <button class="save" @click="save({ count })">Save</button> 9 </div> 10</template> 11 12<script> 13import { mapState, mapGetters, mapActions, mapMutations } from 'vuex' 14 15export default { 16 computed: { 17 ...mapState(['count']), 18 ...mapGetters(['doubleCount']), 19 }, 20 methods: { 21 ...mapMutations(['increment', 'decrement']), 22 ...mapActions(['save']), 23 }, 24} 25</script>
You can test interactions without relying on the behaviour of your actions and mutations:
1import { Store } from 'vuex-mock-store' 2import { mount } from '@vue/test-utils' 3import MyComponent from '@/components/MyComponent.vue' 4 5// create the Store mock 6const store = new Store({ 7 state: { count: 0 }, 8 getters: { doubleCount: 0 }, 9}) 10// add other mocks here so they are accessible in every component 11const mocks = { 12 global: { $store: store }, 13 // for Vue 2.x: just { $store: store } without global 14} 15 16// reset spies, initial state and getters 17afterEach(() => store.reset()) 18 19describe('MyComponent.vue', () => { 20 let wrapper 21 beforeEach(() => { 22 wrapper = mount(MyComponent, { mocks }) 23 }) 24 25 it('calls increment', () => { 26 wrapper.find('button.increment').trigger('click') 27 expect(store.commit).toHaveBeenCalledOnce() 28 expect(store.commit).toHaveBeenCalledWith('increment') 29 }) 30 31 it('dispatch save with count', () => { 32 wrapper.find('button.save').trigger('click') 33 expect(store.dispatch).toHaveBeenCalledOnce() 34 expect(store.dispatch).toHaveBeenCalledWith('save', { count: 0 }) 35 }) 36})
⚠️ The mocked dispatch
method returns undefined
instead of a Promise. If you rely on this, you will have to call the appropriate function to make the dispatch
spy return a Promise:
1store.dispatch.mockReturnValue(Promise.resolve(42))
If you are using Jest, you can check the documentation here
You can provide a getters
, and state
object to mock them:
1const store = new Store({ 2 getters: { 3 name: 'Eduardo', 4 }, 5 state: { 6 counter: 0, 7 }, 8})
To mock module's state
, provide a nested object in state
with the same name of the module. As if you were writing the state yourself:
1new Store({
2 state: {
3 value: 'from root',
4 moduleA: {
5 value: 'from A',
6 moduleC: {
7 value: 'from A/C',
8 },
9 },
10 moduleB: {
11 value: 'from B',
12 },
13 },
14})
That will cover the following calls:
1import { mapState } from 'vuex' 2 3mapState(['value']) // from root 4mapState('moduleA', ['value']) // from A 5mapState('moduleB', ['value']) // from B 6mapState('moduleA/moduleC', ['value']) // from C
When testing state
, it doesn't change anything for the module to be namespaced or not
To mock module's getters
, provide the correct name based on whether the module is namespaced or not. Given the following modules:
1const moduleA = { 2 namespaced: true, 3 4 getters: { 5 getter: () => 'from A', 6 }, 7 8 // nested modules 9 modules: { 10 moduleC: { 11 namespaced: true, 12 getter: () => 'from A/C', 13 }, 14 moduleD: { 15 // not namespaced! 16 getter: () => 'from A/D', 17 }, 18 }, 19} 20 21const moduleB = { 22 // not namespaced 23 getters: { 24 getter: () => 'from B', 25 }, 26} 27 28new Vuex.Store({ modules: { moduleA, moduleC } })
We need to use the following getters:
1new Store({
2 getters: {
3 getter: 'from root',
4 'moduleA/getter': 'from A',
5 'moduleA/moduleC/getter': 'from A/C',
6 'moduleA/getter': 'from A/D', // moduleD isn't namespaced
7 'moduleB/getter': 'from B',
8 },
9})
As with getters, testing actions and mutations depends whether your modules are namespaced or not. If they are namespaced, make sure to provide the full action/mutation name:
1// namespaced module 2expect(store.commit).toHaveBeenCalledWith('moduleA/setValue') 3expect(store.dispatch).toHaveBeenCalledWith('moduleA/postValue') 4// non-namespaced, but could be inside of a module 5expect(store.commit).toHaveBeenCalledWith('setValue') 6expect(store.dispatch).toHaveBeenCalledWith('postValue')
Refer to the module example below using getters
for a more detailed example, even though it is using only getters
, it's exactly the same for actions
and mutations
state
, providing custom getters
You can modify the state
and getters
directly for any test. Calling store.reset()
will reset them to the initial values provided.
Store
classconstructor(options)
options
state
: initial state object, default: {}
getters
: getters object, default: {}
spy
: interface to create spies. details belowstate
Store state. You can directly modify it to change state:
1store.state.name = 'Jeff'
getters
Store getters. You can directly modify it to change a value:
1store.getters.upperCaseName = 'JEFF'
ℹ️ Why no functions?: if you provide a function to a getter, you're reimplementing it. During a test, you know the value, you should be able to provide it directly and be completely sure about the value that will be used in the component you are testing.
reset
Reset commit
and dispatch
spies and restore getters
and state
to their initial values
By default, the Store will call jest.fn()
to create the spies. This will throw an error if you are using mocha
or any other test framework that isn't Jest. In that situation, you will have to provide an interface to create spies. This is the default interface that uses jest.fn()
:
1new Store({ 2 spy: { 3 create: (handler) => jest.fn(handler), 4 }, 5})
The handler is an optional argument that mocks the implementation of the spy.
If you use Jest, you don't need to do anything. If you are using something else like Sinon, you could provide this interface:
1import sinon from 'sinon' 2 3new Store({ 4 spy: { 5 create: (handler) => sinon.spy(handler), 6 }, 7})
commit
& dispatch
Spies. Dependent on the testing framework
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
license file detected
Details
Reason
9 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 7
Reason
9 existing vulnerabilities detected
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
security policy file not detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More