[FEAT] Add end-to-end smoke tests that start the function runtime and hit HTTP endpoints

[colbytimm]

Summary

Add E2E tests that actually start the generated API server (using Azure Functions Core Tools, functions-framework, or a lightweight HTTP adapter), send real HTTP requests to each CRUD endpoint, and validate responses. This catches issues that unit tests miss: routing configuration, serialization, middleware, and request/response mapping. Uses a mocked or in-memory database to avoid external dependencies.

Category: testing

Acceptance Criteria

• Each template includes a tests/e2e/ directory with E2E test files
• Tests start the function runtime in the background (or use a test HTTP client/adapter)
• Tests cover all 5 CRUD endpoints:
  • POST /{endpoint} — Create an item, assert 201 + response body
  • GET /{endpoint}/{id} — Get item by ID, assert 200 + correct body
  • GET /{endpoint} — List items, assert 200 + array response
  • PATCH /{endpoint}/{id} — Update item, assert 200 + updated fields
  • DELETE /{endpoint}/{id} — Soft delete, assert 200/204
• Tests validate HTTP status codes, response body structure, and content-type headers
• Makefile adds test-e2e target
• CI pipeline adds an E2E test step (on Ubuntu only to keep CI costs down)
• Uses mock/in-memory database (not emulator) to keep this independent from integration test stories

Implementation Notes

Approach Options per Language

Python (Azure):

• Use Azure Functions Core Tools (func start) in background + httpx or requests for HTTP calls
• Alternative: Use Flask/ASGI test client to bypass the function host entirely

Python (GCP):

• Use functions-framework in background + httpx for HTTP calls
• Or use werkzeug.test.Client directly

TypeScript (Azure):

• Use Azure Functions Core Tools or supertest with the Express-like handler
• Alternative: undici or node-fetch against func start

TypeScript (GCP):

• Use functions-framework in background + supertest or fetch

Go:

• Use net/http/httptest to test handlers directly (no external process needed)
• This is the most natural approach for Go

.NET:

• Use Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory for in-process testing
• Or start func start in background + HttpClient

Test Lifecycle

1. Setup: Start function runtime (or create test client)
2. Wait: Health check / retry until server responds
3. Execute: Run HTTP requests against each endpoint
4. Assert: Validate status codes + response bodies
5. Teardown: Stop the function runtime

Key Consideration

These tests use mocked/stubbed repositories (not real databases). The goal is to validate the HTTP layer, routing, serialization, and request validation — not database connectivity (that's what integration tests are for).