Problem
Several core modules have no dedicated test file and are covered only incidentally via integration tests in client-test.js:
src/http.ts (346 LOC)
src/utils.ts (266 LOC)
src/nscontext.ts (232 LOC)
src/soap.ts (100 LOC)
src/types.ts (144 LOC — type-only, maybe N/A)
Why it matters
Integration tests catch happy paths. Edge cases (malformed namespaces, unusual HTTP response shapes, utility boundary conditions) usually fall through the cracks. Once coverage (#4) is in place this gap will show up quantitatively.
Proposed approach
For each module, add a test/<module>-test.js exercising:
- Every exported function.
- Edge cases not naturally hit by client tests (empty input, nulls, malformed shapes).
- Error paths.
Skip types.ts if it's purely interface declarations.
Acceptance criteria
Problem
Several core modules have no dedicated test file and are covered only incidentally via integration tests in
client-test.js:src/http.ts(346 LOC)src/utils.ts(266 LOC)src/nscontext.ts(232 LOC)src/soap.ts(100 LOC)src/types.ts(144 LOC — type-only, maybe N/A)Why it matters
Integration tests catch happy paths. Edge cases (malformed namespaces, unusual HTTP response shapes, utility boundary conditions) usually fall through the cracks. Once coverage (#4) is in place this gap will show up quantitatively.
Proposed approach
For each module, add a
test/<module>-test.jsexercising:Skip
types.tsif it's purely interface declarations.Acceptance criteria