Expand endpoint.spec.ts CSAPI section from 3 to ~6 test cases

[Sam-Bolling]

Task

Expand the CSAPI section of endpoint.spec.ts from 3 test cases to ~6 test cases. The current coverage only verifies hasConnectedSystems (true/false) and csapiCollections list, leaving several important endpoint behaviors untested.

Finding Reference: F-NEW-08 from final-project-code-review.md
Severity: Minor (GAP)
Category: Test coverage gap
Implementation Branch: phase-6

---

Problem Statement

The CSAPI section of endpoint.spec.ts (lines ~2836–2865, 3 test cases) provides only minimal coverage:

1. hasConnectedSystems → true — Endpoint with CSAPI conformance classes
2. csapiCollections — Returns the list of CSAPI-conformant collections
3. hasConnectedSystems → false — Endpoint without CSAPI conformance classes

This leaves several gaps:

Missing Test Case	Why It Matters
getCollectionDocument direct call	The CSAPI factory relies on getCollectionDocument() to fetch individual collection metadata — this method is not directly tested in the CSAPI context
Empty collections array	Endpoint conforms to CSAPI but has zero matching collections — csapiCollections should return [], not throw
Conformance without matching collections	Endpoint advertises CSAPI conformance classes but no collection has the required itemType or link relations — edge case that could surface in the wild

Impact: OgcApiEndpoint is the integration surface that factory and consumers depend on. Gaps here mean edge cases discovered in production.

Files to Create or Modify

File	Action	Est. Lines	Purpose
src/ogc-api/endpoint.spec.ts	Modify	~60–100 added	Add 3+ test cases to the CSAPI describe block
fixtures/ogc-api/ (if needed)	Create	~30–80	Fixture data for new test scenarios

Proposed Fix

Add the following test cases to the CSAPI section of endpoint.spec.ts:

Test 1: getCollectionDocument direct call

Call getCollectionDocument() for a known CSAPI collection. Verify it returns the expected collection document with CSAPI-specific fields (links, itemType, etc.).

Test 2: Empty CSAPI collections

Mock an endpoint that has CSAPI conformance classes in its conformance document but no collections with matching CSAPI characteristics. Verify csapiCollections returns [] and hasConnectedSystems still returns true (conformance is present even if no collections match).

Test 3: Conformance without matching collections

Mock an endpoint where the conformance document includes CSAPI classes but the collections lack the required itemType: "feature" or CSAPI-specific link relations. Verify the endpoint correctly reports conformance but returns an empty (or appropriately filtered) collection list.

Each test should follow the existing patterns in endpoint.spec.ts:

• Use the fixture-based mocking approach (fetch interceptor)
• Mirror the structure of existing CSAPI tests in the describe('CSAPI') block

Scope — What NOT to Touch

• ❌ Do NOT modify endpoint.ts implementation (this is test-only)
• ❌ Do NOT modify factory.ts, factory.spec.ts, url_builder.ts, or index.ts
• ❌ Do NOT modify any parser or format handler
• ❌ Do NOT modify any CSAPI business logic
• ❌ Do NOT add integration tests or live server calls — unit tests only

Acceptance Criteria

• CSAPI section of endpoint.spec.ts contains ≥6 test cases (current 3 + ≥3 new)
• All new tests verify a distinct behavior path through the CSAPI endpoint methods
• All new tests use consistent fixture/mocking patterns with existing tests
• npm run test:node passes
• npm run lint passes
• No changes to any .ts file outside endpoint.spec.ts (and optional fixture files)

Dependencies

Blocked by: Nothing (independent of #129, #130, #131, #132)
Blocks: Nothing

---

Operational Constraints

⚠️ MANDATORY: Before starting work on this issue, review docs/governance/AI_OPERATIONAL_CONSTRAINTS.md.

Key constraints:

• Precedence: OGC specifications → AI Collaboration Agreement → This issue description → Existing code → Conversational context
• No scope expansion: Add tests to endpoint.spec.ts CSAPI section, nothing more
• Minimal diffs: Follow existing test patterns and style
• No implementation changes: If a test reveals an endpoint bug, file a new issue rather than fixing it in this PR

---

References

#	Document	What It Provides
1	final-project-code-review.md §9 F-NEW-08	Finding evidence and context
2	src/ogc-api/endpoint.spec.ts lines ~2836–2865	Current 3 CSAPI test cases
3	src/ogc-api/endpoint.ts	Endpoint implementation with CSAPI methods
4	findings-effort-assessment.md	Effort assessment (bundled with F-NEW-07 as 1 pass)
5	Issue #132	Sibling task — factory.spec.ts expansion (recommended to implement together)
6	01-edr-test-blueprint.md	EDR integration tests (13 scenarios in endpoint.spec.ts) — upstream model accepted by jahow in PR #114
7	02-upstream-test-consistency.md	Universal test patterns — integration tests in endpoint.spec.ts is standard across all 6 implementations
8	22-conformance-capability-testing.md	Conformance class catalog and server profiles — see URI caveat below
9	14-integration-test-workflow-design.md §3	Discovery workflow scenarios — existing tests cover detection/listing, expansion adds edge cases

---

Testing Research Context

Note: The testing research at docs/research/testing/findings/ was conducted before Phase 6. It covers the broader CSAPI testing vision (~26 integration workflows, ~280 error scenarios, 8+ server profiles). That broader vision is not Phase 6 scope. Only the references directly applicable to this issue's scope (expanding the CSAPI section from 3 to ~6 tests) are included above. Phase 6's goal (per P6-contribution-goal-and-definition.md) is to satisfy jahow's architectural requirements and pass upstream CI.

Key insights from research:

1. EDR precedent (Finding 01 §1): The EDR section in endpoint.spec.ts has 13 integration test scenarios across conformance detection, collection listing, query building, and error handling (298 lines added). The CSAPI section currently has 3 tests (~30 lines). The EDR section is the direct upstream model that jahow accepted in PR parseResourceRef() should normalize type to rt for OSH @link objects (P5-F5) #114. While expanding to 13 scenarios is not required, the comparison shows significant room to strengthen the CSAPI section.

2. Upstream consistency (Finding 02): Integration tests in endpoint.spec.ts are the standard pattern across all 6 upstream implementations (WFS, WMS, WMTS, TMS, STAC, EDR). The existing 3 CSAPI tests already follow the conventions: fixture-driven fetch mocking, describe/it blocks, beforeEach setup. New tests should continue this pattern.

3. Conformance landscape (Finding 22 §1–§2): Documents 25 modular CSAPI conformance classes across Parts 1 and 2. Real server profiles: OpenSensorHub = full conformance (33/33 classes), 52°North = partial Part 2 (DataStreams only, no ControlStreams). §2.3 provides 6 minimum viable configuration profiles with ready-to-use conformsTo JSON arrays.

⚠️ CRITICAL: Conformance URI Caveat

Finding 22's conformance class catalog uses URI patterns from the specification annexes (e.g., /conf/api-common, /conf/system, /conf/datastream). However, the actual code (checkHasConnectedSystems at src/ogc-api/info.ts:112) checks for only two specific URIs:

• http://www.opengis.net/spec/ogcapi-connectedsystems-1/1.0/conf/core (Part 1)
• http://www.opengis.net/spec/ogcapi-connectedsystems-2/1.0/conf/dynamic-data (Part 2)

Any new test fixtures must use these URIs (which the existing fixture at fixtures/ogc-api/csapi/sample-data-hub/conformance.json already uses correctly). Do not derive fixture URIs from Finding 22's annex tables — test what the code actually checks.

4. checkHasConnectedSystems logic (src/ogc-api/info.ts:112): Returns true if the conformance array contains either conf/core (Part 1) OR conf/dynamic-data (Part 2). This means:

   • An endpoint with only Part 1 conformance → true
   • An endpoint with only Part 2 conformance → true
   • An endpoint with both → true (current fixture)
   • An endpoint with neither → false (already tested)
   • Testing Part 1-only and Part 2-only detection are potential additional test cases that would strengthen coverage of this OR-logic.

5. csapiCollections filtering chain (src/ogc-api/endpoint.ts:230):

   • Promise.all([this.data, this.hasConnectedSystems]) — parallel fetch
   • If !hasCSAPI, short-circuits to { collections: [] } (already tested via non-CSAPI case)
   • Otherwise: parseCollections() → .filter(c => c.hasConnectedSystems) → .map(c => c.name)
   • Untested path: Conformance passes but no collection has CSAPI link relations (e.g., ogc-cs:systems, ogc-cs:datastreams) → should return []. This maps directly to proposed Tests 2 and 3.

6. Discovery workflow (Finding 14 §3): The existing 3 tests cover the core Discovery scenarios (conformance detection true/false, collection listing). The proposed expansion adds the edge cases that were identified as distinct scenarios in the research but not yet implemented.