Adds comprehensive BDD test scenarios for configuration hot reloading functionality: - 10 scenarios covering hot reloading of logging level, feature flags, telemetry settings, JWT TTL - Scenarios for handling invalid configurations, file deletion/recreation, rapid changes - Audit logging scenarios for configuration changes - All scenarios follow black box testing principles using actual HTTP endpoints The scenarios are marked as pending since the hot reloading feature is not yet implemented. They will serve as executable specifications for the future implementation. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
73 lines
3.5 KiB
Gherkin
73 lines
3.5 KiB
Gherkin
# features/config_hot_reloading.feature
|
|
Feature: Config Hot Reloading
|
|
The system should support selective hot reloading of configuration changes
|
|
|
|
Scenario: Hot reloading logging level changes
|
|
Given the server is running with config file monitoring enabled
|
|
When I update the logging level to "debug" in the config file
|
|
Then the logging level should be updated without restart
|
|
And debug logs should appear in the output
|
|
|
|
Scenario: Hot reloading feature flags
|
|
Given the server is running with config file monitoring enabled
|
|
And the v2 API is disabled
|
|
When I enable the v2 API in the config file
|
|
Then the v2 API should become available without restart
|
|
And v2 API requests should succeed
|
|
|
|
Scenario: Hot reloading telemetry sampling settings
|
|
Given the server is running with config file monitoring enabled
|
|
And telemetry is enabled
|
|
When I update the sampler type to "parentbased_traceidratio" in the config file
|
|
And I set the sampler ratio to "0.5" in the config file
|
|
Then the telemetry sampling should be updated without restart
|
|
And the new sampling settings should be applied
|
|
|
|
Scenario: Hot reloading JWT TTL
|
|
Given the server is running with config file monitoring enabled
|
|
And JWT TTL is set to 1 hour
|
|
When I update the JWT TTL to 2 hours in the config file
|
|
Then the JWT TTL should be updated without restart
|
|
And new JWT tokens should have the updated expiration
|
|
|
|
Scenario: Attempting to hot reload non-reloadable settings should be ignored
|
|
Given the server is running with config file monitoring enabled
|
|
When I update the server port to 9090 in the config file
|
|
Then the server port should remain unchanged
|
|
And the server should continue running on the original port
|
|
And a warning should be logged about ignored configuration change
|
|
|
|
Scenario: Invalid configuration changes should be handled gracefully
|
|
Given the server is running with config file monitoring enabled
|
|
When I update the logging level to "invalid_level" in the config file
|
|
Then the logging level should remain unchanged
|
|
And an error should be logged about invalid configuration
|
|
And the server should continue running normally
|
|
|
|
Scenario: Config file monitoring should handle file deletion gracefully
|
|
Given the server is running with config file monitoring enabled
|
|
When I delete the config file
|
|
Then the server should continue running with last known good configuration
|
|
And a warning should be logged about missing config file
|
|
|
|
Scenario: Config file monitoring should handle file recreation
|
|
Given the server is running with config file monitoring enabled
|
|
And I have deleted the config file
|
|
When I recreate the config file with valid configuration
|
|
Then the server should reload the configuration
|
|
And the new configuration should be applied
|
|
|
|
Scenario: Multiple rapid configuration changes should be handled
|
|
Given the server is running with config file monitoring enabled
|
|
When I rapidly update the logging level multiple times
|
|
Then all changes should be processed in order
|
|
And the final configuration should be applied
|
|
And no configuration changes should be lost
|
|
|
|
Scenario: Configuration changes should be audited
|
|
Given the server is running with config file monitoring enabled
|
|
And audit logging is enabled
|
|
When I update the logging level to "info" in the config file
|
|
Then an audit log entry should be created
|
|
And the audit entry should contain the previous and new values
|
|
And the audit entry should contain the timestamp of the change |