MockInterceptor: `.reply` should be LIFO about undici HOT 4 OPEN

I think FIFO is the most correct.

The problem in your test is that you are not creating a new mock for each test.

from undici.

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 'should get with a mock') and Jest. Sinon.JS doesn't show it in the docs, but you can also change the return value of a stub in an imperative way.

Additionally, those libraries offer the way of resetting the mock/stub behavior (.mockReset(), .resetBehavior()). In Undici, after setting a persistent interceptor, there's no way back.

I see that Undici's MockAgent is heavily inspired by Nock, where behavior is exactly the same... Although there you can at least .deleteInterceptor() 😄 (kinda hacky though).

from undici.

Actually, when I'm thinking about it, it's not about FIFO vs LIFO per se, but rather the .persist() having the same priority as one-time interceptors.

From the linked fragment of Jest docs:

When the mocked function runs out of implementations defined with .mockImplementationOnce(), it will execute the default implementation set with jest.fn(() => defaultValue) or .mockImplementation(() => defaultValue) if they were called:

And then it follows the intuition - on one hand, you can chain multiple calls of mockImplementationOnce and it'll be FIFO, but on the other hand you don't have to ensure that the default implementation is provided as the last one.

Maybe .persist() should allow setting the lowest priority? It could be an argument or a separate method.

from undici.

I'm not really in sync with changing the behaviour to sync with other test runners. Overall the intention of Undici mocks seems to be as declarative as possible and scoped to single test scenarios (even if there are a few dozen, but that's more about test strategy and that's another topic).

That being said, I do see value in having a way to reset the mocks from a fake Agent.

from undici.