How to set/mock auth state in tests?

[litewarp]

This could be my sleep-deprived brain misfiring, but how would one set the auth state on a rendering test for a component?

The WithAuthUser HOC checks the return value of useFirebaseUser, and the tests for the package mock that function as well.

useFirebaseUser.mockReturnValue({
  user: createMockFirebaseUserClientSDK(),
  initialized: true,
})

However, because useFirebaseUser is not exported from the package, I can't seem to stub it properly in my app so my components wrapped in the HOC never render. Anyone got any ideas?

Thanks in advance.

[kmjennison]

We do this by mocking next-firebase-auth rather than worrying about its internal logic:

// ./__mocks__/next-firebase-auth/withAuthUser.js
// the mock just renders its child component
const withAuthUser = jest.fn(() => (wrappedComponent) => wrappedComponent)
export default withAuthUser

// ./__mocks__/next-firebase-auth/useAuthUser.js
import getMockAuthUser from './my/test/utils'
const useAuthUser = jest.fn(() => getMockAuthUser())
export default useAuthUser

Then, in tests, set the useAuthUser return value:

useAuthUser.mockReturnValue(someValue)

If you wanted to, you could make your mocks more sophisticated so that the withAuthUser mock provides context to the useAuthUser mock, though you would probably end up replicating a lot of next-firebase-auth behavior.

Alternatively, if you chose not to mock next-firebase-auth at all, you'd want to mock the underlying Firebase libraries and likely also intercept network calls this package makes. This has the disadvantage of being much more complex and prone to breaking as this package changes, but it has the advantage of not implicitly trusting 3rd party code for critical auth logic.

[grahaml]

Thanks very much for sharing the examples @kmjennison. FWIW it took me awhile to get this working, and it is kind of critical for any app using this library, as I expect I'll use these functions a lot. It might be worthwhile to add some documentation around this piece? I could try to have a crack at that. Would the right place to start be opening an issue for that?

[kmjennison]

@grahaml Sure, that sounds great! Yes, feel free to open an issue and take it on. Happy to add an "examples" section to the README.

[grahaml]

I'll see what I can do!

[grahaml]

Opened #133 to capture this. I'll try to tackle it over the next few days, while it's fresh in my mind.

[grahaml]

Had a spare cycle this afternoon so finessed something I wrote for my app's README to make it a bit more generic for this repo. See #134.