Gabriel Radureau
61837b7385
Pre-existing latent bug surfaced by the new @v2-gate scenario in greet.feature (added in PR #56 follow-up): shouldEnableV2 used strings.Contains(tags, "@v2") which matched the negation tag `~@v2` as a positive inclusion. Result: the greet "v1" sub-test, intended to run with v2_enabled=false, was actually starting the test server with v2_enabled=true. The @v2-gate scenario asserting "v2 disabled → 404" got 200 instead. Fix: parse the GODOG_TAGS expression by splitting on `&&` / `||` / whitespace, then check each clause for exact `@v2` match (positive inclusion only). The negation `~@v2` no longer matches. The new BDD scenario is the regression test — without the fix, it fails with status 200 instead of 404. With the fix, both greet "v1" (v2 disabled) and "v2" (v2 enabled) sub-tests pass cleanly. Verifier verdict: APPROVE. Race-clean. Full BDD suite green.
65 lines
2.9 KiB
Gherkin
65 lines
2.9 KiB
Gherkin
# features/greet.feature
|
|
@greet @smoke
|
|
Feature: Greet Service
|
|
The greet service should return appropriate greetings
|
|
|
|
@basic
|
|
Scenario: Default greeting
|
|
Given the server is running
|
|
When I request the default greeting
|
|
Then the response should be "{\"message\":\"Hello world!\"}"
|
|
|
|
@basic
|
|
Scenario: Personalized greeting
|
|
Given the server is running
|
|
When I request a greeting for "John"
|
|
Then the response should be "{\"message\":\"Hello John!\"}"
|
|
|
|
@critical @v2-gate
|
|
Scenario: v2 endpoint returns 404 when api.v2_enabled is disabled
|
|
# In the default tag-filter run (~@v2), the test server starts with
|
|
# v2_enabled=false. The v2EnabledGate middleware (ADR-0023 Phase 4)
|
|
# returns 404 with a JSON body explaining the flag state.
|
|
Given the server is running
|
|
When I send a POST request to v2 greet with name "John"
|
|
Then the status code should be 404
|
|
And the response should contain "v2 API is currently disabled"
|
|
|
|
@v2 @api
|
|
Scenario: v2 greeting with JSON POST request
|
|
Given the server is running with v2 enabled
|
|
When I send a POST request to v2 greet with name "John"
|
|
Then the response should be "{\"message\":\"Hello my friend John!\"}"
|
|
|
|
@v2 @api
|
|
Scenario: v2 default greeting with empty name
|
|
Given the server is running with v2 enabled
|
|
When I send a POST request to v2 greet with name ""
|
|
Then the response should be "{\"message\":\"Hello my friend!\"}"
|
|
|
|
@v2 @api
|
|
Scenario: v2 greeting with missing name field
|
|
Given the server is running with v2 enabled
|
|
When I send a POST request to v2 greet with invalid JSON "{}"
|
|
Then the response should be "{\"message\":\"Hello my friend!\"}"
|
|
|
|
@v2 @api
|
|
Scenario: v2 greeting with name that is too long
|
|
Given the server is running with v2 enabled
|
|
When I send a POST request to v2 greet with name "ThisNameIsWayTooLongAndShouldFailValidationBecauseItExceedsTheMaximumAllowedLengthOf100Characters!!!!"
|
|
Then the response should contain error "validation_failed"
|
|
|
|
@ratelimit @skip @bdd-deferred
|
|
# NOTE: Functional behavior validated by unit tests in pkg/middleware/ratelimit_test.go.
|
|
# BDD scenario currently skipped: env-var-based rate limit config does not reach the
|
|
# already-started test server (architectural limitation of testsetup, not the middleware).
|
|
# TODO: rework testserver to allow per-scenario rate limit config (admin endpoint or
|
|
# per-scenario fresh server), then re-enable this scenario.
|
|
Scenario: Greet endpoint rejects requests over the rate limit
|
|
Given the server is running with rate limit set to 3 requests per minute and burst 3
|
|
When I make 3 requests to "/api/v1/greet/Alice"
|
|
Then all responses should have status 200
|
|
When I make 1 more request to "/api/v1/greet/Alice"
|
|
Then the response should have status 429
|
|
And the response body should contain "rate_limited"
|
|
And the response should have header "Retry-After" |