-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MockInterceptor: .reply
should be LIFO
#2637
Comments
I think FIFO is the most correct. The problem in your test is that you are not creating a new mock for each test. |
My real-life use case is a series of integration tests that cover a broad range of API requests (a few dozen). I don't want to think which requests will exactly be executed in a certain test, so I'd rather just take a full API mock and add needed overrides. While a workaround is indeed fairly easy: const createMockAgent = afterInit => {
const mockAgent = new MockAgent()
mockAgent.disableNetConnect()
const mockPool = mockAgent.get('https://api.example.com')
afterInit?.(mockPool) // a hook for adding overrides
// defaults
mockPool
.intercept({
path: '/folders/123',
})
.reply(200, {id: 123, name: 'mocked folder'})
.persist()
mockPool.intercept({path: '/folders/456'}).reply(404).persist()
return mockAgent
}
const mockAgent = createMockAgent(mockPool => {
// let's simulate a temporary downtime
mockPool
.intercept({
path: '/folders/123',
})
.reply(502)
.delay(1000)
.times(2)
}) I just think that it's not what the users are used to, at least the ones familiar with function mocking. The pattern of overriding an initial mock behavior is shown in the docs of Vitest (test Additionally, those libraries offer the way of resetting the mock/stub behavior ( I see that Undici's MockAgent is heavily inspired by Nock, where behavior is exactly the same... Although there you can at least |
Actually, when I'm thinking about it, it's not about FIFO vs LIFO per se, but rather the From the linked fragment of Jest docs:
And then it follows the intuition - on one hand, you can chain multiple calls of Maybe |
I'm not really in sync with changing the behaviour to sync with other test runners. Overall the intention of That being said, I do see value in having a way to reset the mocks from a fake Agent. |
This would solve...
Let's imagine a following test suite:
The retry handling test should fail, but it does not, because once you set a persistent interceptor, there is no way to override it or delete it. It's counterintuitive to the mocks known from the test runners, where you have methods like
mockImplementationOnce
:The implementation should look like...
I suppose that
addMockDispatch
should use.unshift
instead of.push
, so that new mocks have a top priority.I have also considered...
...adding an equivalent of
mock.restore()
from Node test runner. Now I don't see any way to delete, temporarily disable, or unpersist the mock. It could be a part of the MockScope class.The text was updated successfully, but these errors were encountered: