Testing the full stack
HTTP handler tests exercise API endpoints from request to response. A single request might authenticate a user, check permissions, validate input, query a database, update a cache, and write an audit log. Testing handlers end to end catches bugs that unit tests miss. Every handler should have tests for success, validation errors, authentication errors, and authorization errors.Anatomy of a handler test
Create a test harness, configure the handler with harness dependencies, register the handler, create credentials, make a request, and verify the response.Organizing test files
Organize tests by behavior so the intent is clear. Example directory:svc/api/routes/v2_apis_create_api/.
Typical files:
svc/api/routes/v2_apis_create_api/handler.gosvc/api/routes/v2_apis_create_api/success_test.gosvc/api/routes/v2_apis_create_api/validation_test.gosvc/api/routes/v2_apis_create_api/auth_test.gosvc/api/routes/v2_apis_create_api/BUILD.bazel
Testing success cases
Test minimal requests, full requests, and any important variations. Verify side effects such as audit log writes when relevant.Testing validation errors
Test boundary conditions, missing required fields, and invalid formats. These tests document the API contract.Testing authentication
Reject missing headers, malformed tokens, and revoked credentials.Testing authorization
Verify that permissions are enforced and cross-workspace access is rejected.Helper functions
Extract repeated setup into helpers. If a helper asserts, it must callt.Helper().

