Skip to content

[test-improver] Improve tests for server http_helpers package#3212

Draft
github-actions[bot] wants to merge 1 commit intomainfrom
test-improver/http-helpers-coverage-5b94feec52773d2b
Draft

[test-improver] Improve tests for server http_helpers package#3212
github-actions[bot] wants to merge 1 commit intomainfrom
test-improver/http-helpers-coverage-5b94feec52773d2b

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot commented Apr 5, 2026

Test Improvements: internal/server/http_helpers_test.go

File Analyzed

  • Test File: internal/server/http_helpers_test.go
  • Package: internal/server
  • Lines of Code: 733 → 867 (+134 lines)

Improvements Made

1. Increased Coverage — Direct Tests for writeErrorResponse

Problem: writeErrorResponse in http_helpers.go is the canonical helper called by every HTTP error path in the server package (auth rejections, shutdown rejections, etc.). Despite this central role, it had no dedicated unit test — it was only exercised indirectly via higher-level tests such as TestWrapWithMiddleware.

New test: TestWriteErrorResponse — 6 subtests covering all common HTTP error status codes:

  • 400 Bad Request — verifies bad_request error code and message
  • 401 Unauthorized — verifies unauthorized error code
  • 403 Forbidden — verifies forbidden error code
  • 404 Not Found — verifies not_found error code
  • 500 Internal Server Error — verifies internal_error error code
  • 503 Service Unavailable — verifies service_unavailable error code

Each subtest asserts:

  • HTTP status code matches the input
  • Content-Type: application/json header is set
  • Response body is valid JSON
  • "error" field equals the code argument
  • "message" field equals the message argument

2. Increased Coverage — Direct Tests for rejectRequest

Problem: rejectRequest composes logRuntimeError + writeErrorResponse into a single call used at every request-rejection site. It had no direct test — its behavior was only observed through integration-style middleware tests.

New test: TestRejectRequest — 3 subtests covering realistic rejection scenarios:

  • 401 missing Authorization header — auth rejection path
  • 401 invalid API key — key mismatch rejection path
  • 503 Gateway shutting down — shutdown rejection path

Each subtest asserts:

  • No panic occurs for any valid input
  • HTTP status code matches
  • Content-Type: application/json header is set
  • Response body is valid JSON with correct "error" and "message" fields

3. Cleaner & More Stable Tests

  • ✅ Table-driven tests with descriptive names following existing file conventions
  • ✅ Added "encoding/json" import (only addition to the import block)
  • ✅ Uses require.NoError for JSON decode (stops test on body parse failure before further assertions)
  • ✅ Uses assert.Equal for all field-level checks (clear diff output on failure)
  • ✅ Isolated: each subtest creates its own httptest.NewRecorder() and httptest.NewRequest() — no shared state

Why These Changes?

writeErrorResponse is the single source of truth for the JSON shape of all HTTP error responses across the server package. A regression there (e.g., wrong field name, wrong content-type) would silently break clients. Despite being simple, it had no direct test. Similarly, rejectRequest — which drives auth and shutdown rejection — was only covered as a side-effect of middleware tests, making failures harder to pinpoint.

These two tests are small, fast, and deterministic: they exercise only in-process HTTP plumbing with no external dependencies.


Generated by Test Improver Workflow
Focuses on better patterns, increased coverage, and more stable tests

Generated by Test Improver ·

These two functions in http_helpers.go were untested:
- writeErrorResponse: called by all HTTP error paths in the server
- rejectRequest: combines structured error logging with HTTP rejection

New tests verify:
- Correct HTTP status codes are written
- Content-Type is application/json for all responses
- Response body is valid JSON with 'error' and 'message' fields
- No panics on any valid input combination

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants