Mocking nested pinia stores with @pinia/testing

[itchonib]

Hello, currently I have Pinia store A that is importing Pinia store B to utilize some of its actions. However, when I use createTestingPinia for my unit test for a component that uses Pinia Store A, I keep receiving an error that Pinia Store B was called with no active pinia.

I currently have mocked Pinia Store B with jest to get around for error, but is there any other way to set up testing with nested pinia stores?

[posva]

I added a test using nested stores and it works: de0b256

Do you have a failing test?

[msawatzky75]

i actually have that already, this issue only surfaces when an action that was supposed to be stubbed without specifying this option calls another action

[TylerOliverMCG]

Did others find a solution to this? It's unclear from the documentation that this should be expected behavior, at least IMO. Generally it's best practice to test functions in isolation. In this case, I would expect to be able to mock Store B and verify that Store A can call a mocked Store B.

Currently mocking any store mocks all stores, which makes it difficult to test one explicit store's behaviors. Having to test the integration between Store A and Store B (and then C, D, etc) can lead to extremely complex tests with a lot submodule mocking. Would really love to be able to have a way to the get the actual version of a single specific store so that these tests can be written in a more maintainable way, it's hard enough to get people to write tests :)

Additionally, I think the documentation should be clarified to point out that creating a testing pinia stubs all stores, not just the one being tested.

[mikhail-filin]

@TylerOliverMCG did you find any workaround? Right now I have some nested stores and need to test only one of them and mock the others. It feels really painful to do so.

[TylerOliverMCG]

I did find a workaround, while it's not pretty it's effective. I moved all my store definitions to an index file and imported them. Then I imported the internal into my tests. Looks something like this (I paraphrased a bit, let me know if there's something specific to help)

// store/AuthStore.ts
export const authStoreInternal = () => {
  /** my auth store **/
})

// store/index.ts
import { authStoreInternal } from "./AuthStore"
import { otherStoreInternal } from "./OtherStore"
import { defineStore } from "pinia"

// Sets up the store with Pinia
export const useAuthStore = defineStore('AuthStore', authStoreInternal)
export const useOtherStore = defineStore('OtherStore', otherStoreInternal)

// store/AuthStore.spec.ts
import { authStoreInternal } from "./AuthStore"'
import { useOtherStore } from "./store"
import { createTestingPinia } from "pinia"

let mockedOtherStore

beforeEach(() => {
  const pinia = createTestingPinia()
  mockedOtherStore = useOtherStore(pinia)
})

describe("Auth Store test", () => {
  it("should call the inner store", () => {
    authStoreInternal()
    expect(mockedOtherStore.innerFunc).toHaveBeenCalled()
  })
})

After I made my prior comment the maintainer marked this outdated. With no one seemingly interested in looking at this, this is the best I can manage. I absolutely hate having to change my code structure to accommodate a unit test, but this is the best I could come up with without modifying the underlying package.

[scvnc]

@TylerOliverMCG I concur completely with your points and I am experiencing the same thing ..

The workaround I'm barking up is to just use the vi.mock mechanism and avoid using testingPinia. I am using setup based stores. As a result of this I start to lose the value of setup-based Pinia stores over just making Vue Composables.

I'm curious if we can find another thread or establish another topic to expose this issue because I suspect this is being buried by the fact that we have an accepted answer here that does not satisfy our use case.