mirror of
https://github.com/axios/axios.git
synced 2026-04-11 02:11:50 +08:00
* fix(http): handle request socket-only errors * test(http): cover socket-only error handling cleanup --------- Co-authored-by: Jason Saayman <jasonsaayman@gmail.com> |
||
|---|---|---|
| .. | ||
| browser | ||
| module | ||
| setup | ||
| smoke | ||
| unit | ||
| README.md | ||
Test Contribution Guide
This guide explains how to contribute tests inside the tests directory.
It is intentionally scoped to this directory only.
Tests Directory Layout
tests/
browser/ # browser runtime tests
setup/ # shared test setup utilities
smoke/ # package-compat smoke suites (esm + cjs)
unit/ # focused unit/behavior tests
Use the runtime-first layout already present in this directory:
- Put browser-runtime behavior in
tests/browser. - Put non-browser focused tests in
tests/unit. - Put packaging/compatibility smoke checks in
tests/smoke/esm/testsandtests/smoke/cjs/tests. - Reuse helpers from
tests/setupinstead of duplicating setup logic.
File Naming Conventions
Follow the existing file patterns:
- Unit tests:
*.test.js - Browser tests:
*.browser.test.js - ESM smoke tests:
*.smoke.test.js - CJS smoke tests:
*.smoke.test.cjs
When adding a new test, match the nearest existing file name pattern in the same subdirectory.
Suite-Specific Authoring Patterns
Unit (tests/unit)
- Keep tests focused on one behavior or API surface.
- For adapter/network behavior, prefer local test servers using utilities from
tests/setup/server.js. - Ensure server cleanup with
try/finallyso tests do not leak resources. - Keep fixtures close to the tests that use them (see
tests/unit/adaptersfor examples).
Representative files:
tests/unit/adapters/http.test.jstests/unit/adapters/fetch.test.jstests/unit/regression.test.js
Browser (tests/browser)
- Use local in-file
MockXMLHttpRequeststyle mocks when testing request behavior. - Replace global XHR in
beforeEachand restore it inafterEach. - Reset spies/mocks in cleanup hooks to keep tests isolated.
- Keep assertions centered on observable request/response behavior.
Representative files:
tests/browser/requests.browser.test.jstests/browser/adapter.browser.test.jstests/browser/defaults.browser.test.js
Smoke (tests/smoke)
- Keep ESM and CJS smoke coverage aligned for compatibility-sensitive behavior.
- If you add a new smoke scenario in one format, add the equivalent in the other format.
- Keep smoke tests small and focused on import/runtime behavior and critical request flows.
Representative files:
tests/smoke/esm/tests/fetch.smoke.test.jstests/smoke/cjs/tests/fetch.smoke.test.cjstests/smoke/esm/tests/basic.smoke.test.jstests/smoke/cjs/tests/basic.smoke.test.cjs
Shared Setup Utilities (tests/setup)
Use shared helpers before introducing new setup code:
tests/setup/server.js- Server lifecycle helpers:
startHTTPServer,stopHTTPServer,stopAllTrackedHTTPServers - Timing helpers:
setTimeoutAsync - Data/stream helpers used by adapter tests
- Server lifecycle helpers:
tests/setup/browser.setup.js- Browser cleanup hook (
afterEach) for clearing test DOM state
- Browser cleanup hook (
General expectation: if a helper can be reused by multiple tests in this directory, add or extend it in tests/setup instead of copying setup code between test files.
Fixtures and Test Data
- Prefer colocated fixtures near the test files that need them.
- Keep fixture names explicit and stable.
- For matrix-like scenarios, prefer concise table-driven cases inside the test file when practical.
Examples of colocated fixtures:
tests/unit/adapters/cert.pemtests/unit/adapters/key.pemtests/unit/adapters/axios.png
Contributor Checklist
Before opening a PR for tests in this directory:
- File is placed in the correct suite directory (
unit,browser, orsmoke). - File name matches the local pattern (
*.test.js,*.browser.test.js,*.smoke.test.js,*.smoke.test.cjs). - Test setup/teardown is explicit and leaves no global/server state behind.
- Shared setup logic uses
tests/setuphelpers where possible. - Smoke tests remain ESM/CJS consistent when behavior is format-sensitive.
- Fixtures are colocated and minimal.
- Assertions are deterministic and avoid unnecessary timing/network flakiness.