В конце концов, я решил эту проблему - проблема не в самих макетах, а в том, что имитируется класс.
Класс LocalStorageGateway
используется для создания частного экземпляра в импортированном модуле Storage
, следующим образом ...
const guestLocal = new LocalStorageGateway(new GuestContext())
Этот статический контекст заставляет исполняемый конструктор выполняться до того, как переменные определены как Storage
- один из первых импортированных модулей.
Есть несколько способов обойти это ...
Вы можете изменить это ...
import Helper from '../../test-helper'
import Storage from '@/storage'
import GuestContext from '@/auth/guest-context'
import UserContext from '@/auth/user-context'
(insert mocks here)
на ...
const mockContextUpsert = jest.fn()
import Helper from '../../test-helper'
import Storage from '@/storage'
import GuestContext from '@/auth/guest-context'
import UserContext from '@/auth/user-context'
например(юк?).
В качестве альтернативы вы можете заключить mockContextUpsert
в функцию обтекания (мой ранее не очень хороший ответ) -> Мне это немного чище.
const mockContextUpsert = jest.fn()
jest.mock('@/storage/local/local-storage-gateway', () => {
return jest.fn().mockImplementation((authContext) => {
return {
authContext: authContext,
context: {
upsert: (cxt) => {
mockContextUpsert(cxt)
}
}
}
})
})
Я также мог бы сделать guestLocal
функцией, но на самом деле я не хочу этого делать и создавать новые экземпляры шлюза каждый раз, когда я хочу его использовать (именно поэтому он существует). Если бы Storage
был классом, он был бы создан в конструкторе, но это не так и не нужно.
Спасибо @Teneff за его вклад в этот вопрос, его ответ заставил мой мозг взглянуть наэто правильный путь. переменные не подняты был ключевым - они работают по-другому - я действовал неправильно, понимая, что все, что называется mockXXXX
, будет поднято над ложными вызовами, но это не так, они просто «разрешены».