Axios Interceptors and Custom Adapters: Testing an Integration Without Production Credentials
0 reputation · 13 Jul 2025, 08:30 UTC
0 reputation · 13 Jul 2025, 08:30 UTC
Axios exposes two extension points that meet at the same boundary: request and response interceptors, registered through axios.interceptors.request.use() and axios.interceptors.response.use(), and the transport adapter selected through the adapter config option in axios 1.x. Interceptors participate in the request pipeline, while the adapter is the layer responsible for producing a response.
A team that wants to exercise an integration flow without production credentials must decide which of these two layers to substitute. Replacing the adapter keeps interceptor logic such as token attachment, header normalization and error mapping inside the path under test. Ejecting or replacing interceptors instead changes the behavior being observed.
The unresolved part is the interaction between the two: whether a custom adapter receives the config as mutated by request interceptors, and whether response interceptors are applied to the adapter's returned response before caller .then() handlers run. Behavior should be confirmed against the installed axios version.
Which layer should be substituted when credentials are unavailable, and should the test assert on the config handed to the adapter or on the value resolved by the caller?
31775 reputation · 13 Jul 2025, 09:16 UTC
Substitute the adapter layer, not the interceptors. This preserves the request/response interceptor chain (token attachment, header normalization, error mapping) inside the test path while isolating the transport mechanism.
Assert on both: verify the config received by your custom adapter to confirm request interceptors mutate it correctly, and verify the value resolved by the caller's .then() to confirm response interceptors transform the adapter's output as expected.
In Axios 1.x, the request pipeline executes in this order:
axios.interceptors.request.use()) run first, each receiving and potentially mutating the config object.AxiosResponse.axios.interceptors.response.use()) run on that response..then() receives the result of the response interceptor chain.Replacing interceptors instead of the adapter removes credential-attachment logic from the test path, so you're no longer exercising the actual integration flow.
config and returns a resolved promise with a minimal AxiosResponse (status, data, headers, config, request).Authorization: Bearer test-token).response.data.axios.request() with your dummy adapter via config.This behavior applies to Axios 1.x (current major version as of 2026). The adapter config option and interceptor pipeline order have been stable since v0.21.
If your codebase uses a custom Axios instance (created via axios.create()) rather than the default export, confirm whether interceptors are registered on that instance or the global default—the test must target the same instance the production code uses.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.