From 6f5055d2dd666a9d7e6b4f145effe7b2aad6bf63 Mon Sep 17 00:00:00 2001
From: Simon Schrottner <simon.schrottner@dynatrace.com>
Date: Thu, 5 Dec 2024 14:18:49 +0100
Subject: [PATCH] feat: improve gherkin files

Signed-off-by: Simon Schrottner <simon.schrottner@dynatrace.com>
---
 gherkin/config.feature               |   7 +-
 gherkin/events.feature               |  32 ++---
 gherkin/flagd-json-evaluator.feature | 182 +++++++++++++++------------
 gherkin/flagd-reconnect.feature      |  21 ++--
 gherkin/flagd-rpc-caching.feature    |  93 ++++++++------
 gherkin/flagd.feature                |  46 ++++---
 6 files changed, 211 insertions(+), 170 deletions(-)

diff --git a/gherkin/config.feature b/gherkin/config.feature
index 350eddf..8b29a58 100644
--- a/gherkin/config.feature
+++ b/gherkin/config.feature
@@ -77,7 +77,7 @@ Feature: Configuration Test
 
   @rpc
   Scenario Outline: Default Config RPC
-    When a config was initialized for "rpc"
+    When a config was initialized
     Then the option "<option>" of type "<type>" should have the value "<default>"
     Examples:
       | option | type    | default |
@@ -85,12 +85,13 @@ Feature: Configuration Test
 
   @in-process
   Scenario Outline: Default Config In-Process
-    When a config was initialized for "in-process"
+    When a config was initialized
     Then the option "<option>" of type "<type>" should have the value "<default>"
     Examples:
       | option | type    | default |
       | port   | Integer | 8015    |
 
+  @rpc @in-process
   Scenario Outline: Dedicated Config
     Given an option "<option>" of type "<type>" with value "<value>"
     When a config was initialized
@@ -142,6 +143,7 @@ Feature: Configuration Test
       | offlineFlagSourcePath | String  | path  |
       | offlinePollIntervalMs | Integer | 1000  |
 
+  @rpc @in-process
   Scenario Outline: Dedicated Config via Env_var
     Given an environment variable "<env>" with value "<value>"
     When a config was initialized
@@ -196,6 +198,7 @@ Feature: Configuration Test
       | offlineFlagSourcePath | FLAGD_OFFLINE_FLAG_SOURCE_PATH | String  | path  |
       | offlinePollIntervalMs | FLAGD_OFFLINE_POLL_MS          | Integer | 1000  |
 
+  @rpc @in-process
   Scenario Outline: Dedicated Config via Env_var and set
     Given an environment variable "<env>" with value "<env-value>"
     And an option "<option>" of type "<type>" with value "<value>"
diff --git a/gherkin/events.feature b/gherkin/events.feature
index 28dd023..03c02f5 100644
--- a/gherkin/events.feature
+++ b/gherkin/events.feature
@@ -1,24 +1,24 @@
-@grace
+@rpc @in-process @grace
 Feature: Flagd Provider State Changes
 
   Background:
-    Given a flagd provider is set
+    Given a unstable flagd provider
 
   Scenario Outline: Provider events
-    When a <event> handler is added
-    Then the <event> handler must run
+    Given a <event> event handler
+    Then the <event> event handler should have been executed
     Examples:
-      | event                          |
-      | PROVIDER_ERROR                 |
-      | PROVIDER_STALE                 |
-      | PROVIDER_READY                 |
+      | event |
+      | error |
+      | stale |
+      | ready |
 
   Scenario: Provider events chain ready -> stale -> error -> ready
-    When a PROVIDER_READY handler is added
-    Then the PROVIDER_READY handler must run
-    When a PROVIDER_STALE handler is added
-    Then the PROVIDER_STALE handler must run
-    When a PROVIDER_ERROR handler is added
-    Then the PROVIDER_ERROR handler must run
-    When a PROVIDER_READY handler is added
-    Then the PROVIDER_READY handler must run
+    Given a ready event handler
+    Then the ready event handler should have been executed
+    Given a stale event handler
+    Then the stale event handler should have been executed
+    Given a error event handler
+    Then the error event handler should have been executed
+    Given a ready event handler
+    Then the ready event handler should have been executed
diff --git a/gherkin/flagd-json-evaluator.feature b/gherkin/flagd-json-evaluator.feature
index f762912..1cafc3b 100644
--- a/gherkin/flagd-json-evaluator.feature
+++ b/gherkin/flagd-json-evaluator.feature
@@ -1,3 +1,4 @@
+@rpc @in-process @targeting
 Feature: flagd json evaluation
 
   # This test suite contains scenarios to test the json-evaluation of flagd and flag-in-process providers.
@@ -5,122 +6,141 @@ Feature: flagd json evaluation
   # It should be used in conjunction with the suites supplied by the OpenFeature specification.
 
   Background:
-    Given a flagd provider is set
+    Given an option "cache" of type "CacheType" with value "disabled"
+    And a stable flagd provider
 
   # evaluator refs
   Scenario Outline: Evaluator reuse
-    When a string flag with key <key> is evaluated with default value "fallback"
-    And a context containing a key "email", with value "ballmer@macrosoft.com"
-    Then the returned value should be <value>
+    Given a String-flag with key "<key>" and a default value "fallback"
+    And a context containing a key "email", with type "String" and with value "ballmer@macrosoft.com"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | key                              | value |
-      | "some-email-targeted-flag"       | "hi"  |
-      | "some-other-email-targeted-flag" | "yes" |
+      | key                            | value |
+      | some-email-targeted-flag       | hi    |
+      | some-other-email-targeted-flag | yes   |
 
   # custom operators
+  @fractional
   Scenario Outline: Fractional operator
-    When a string flag with key "fractional-flag" is evaluated with default value "fallback"
-    And a context containing a nested property with outer key "user" and inner key "name", with value <name>
-    Then the returned value should be <value>
+    Given a String-flag with key "fractional-flag" and a default value "fallback"
+    And a context containing a nested property with outer key "user" and inner key "name", with value "<name>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | name    | value      |
-      | "jack"  | "spades"   |
-      | "queen" | "clubs"    |
-      | "ten"   | "diamonds" |
-      | "nine"  | "hearts"   |
-      | 3       | "diamonds" |
+      | name  | value    |
+      | jack  | spades   |
+      | queen | clubs    |
+      | ten   | diamonds |
+      | nine  | hearts   |
+      | 3     | diamonds |
 
+  @fractional
   Scenario Outline: Fractional operator shorthand
-    When a string flag with key "fractional-flag-shorthand" is evaluated with default value "fallback"
-    And a context containing a targeting key with value <targeting key>
-    Then the returned value should be <value>
+    Given a String-flag with key "fractional-flag-shorthand" and a default value "fallback"
+    And a context containing a targeting key with value "<targeting key>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | targeting key      | value   |
-      | "jon@company.com"  | "heads" |
-      | "jane@company.com" | "tails" |
+      | targeting key    | value |
+      | jon@company.com  | heads |
+      | jane@company.com | tails |
 
+  @fractional
   Scenario Outline: Fractional operator with shared seed
-    When a string flag with key "fractional-flag-A-shared-seed" is evaluated with default value "fallback"
-    And a context containing a nested property with outer key "user" and inner key "name", with value <name>
-    Then the returned value should be <value>
+    Given a String-flag with key "fractional-flag-A-shared-seed" and a default value "fallback"
+    And a context containing a nested property with outer key "user" and inner key "name", with value "<name>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | name    | value      |
-      | "jack"  | "hearts"   |
-      | "queen" | "spades"   |
-      | "ten"   | "hearts"   |
-      | "nine"  | "diamonds" |
+      | name  | value    |
+      | jack  | hearts   |
+      | queen | spades   |
+      | ten   | hearts   |
+      | nine  | diamonds |
 
+  @fractional
   Scenario Outline: Second fractional operator with shared seed
-    When a string flag with key "fractional-flag-B-shared-seed" is evaluated with default value "fallback"
-    And a context containing a nested property with outer key "user" and inner key "name", with value <name>
-    Then the returned value should be <value>
+    Given a String-flag with key "fractional-flag-B-shared-seed" and a default value "fallback"
+    And a context containing a nested property with outer key "user" and inner key "name", with value "<name>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | name    | value             |
-      | "jack"  | "ace-of-hearts"   |
-      | "queen" | "ace-of-spades"   |
-      | "ten"   | "ace-of-hearts"   |
-      | "nine"  | "ace-of-diamonds" |
+      | name  | value           |
+      | jack  | ace-of-hearts   |
+      | queen | ace-of-spades   |
+      | ten   | ace-of-hearts   |
+      | nine  | ace-of-diamonds |
 
+  @string
   Scenario Outline: Substring operators
-    When a string flag with key "starts-ends-flag" is evaluated with default value "fallback"
-    And a context containing a key "id", with value <id>
-    Then the returned value should be <value>
+    Given a String-flag with key "starts-ends-flag" and a default value "fallback"
+    And a context containing a key "id", with type "String" and with value "<id>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | id       | value     |
-      | "abcdef" | "prefix"  |
-      | "uvwxyz" | "postfix" |
-      | "abcxyz" | "prefix"  |
-      | "lmnopq" | "none"    |
-      | 3        | "none"    |
+      | id     | value   |
+      | abcdef | prefix  |
+      | uvwxyz | postfix |
+      | abcxyz | prefix  |
+      | lmnopq | none    |
+      | 3      | none    |
 
+  @semver
   Scenario Outline: Semantic version operator numeric comparison
-    When a string flag with key "equal-greater-lesser-version-flag" is evaluated with default value "fallback"
-    And a context containing a key "version", with value <version>
-    Then the returned value should be <value>
+    Given a String-flag with key "equal-greater-lesser-version-flag" and a default value "fallback"
+    And a context containing a key "version", with type "String" and with value "<version>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | version       | value     |
-      | "2.0.0"       | "equal"   |
-      | "2.1.0"       | "greater" |
-      | "1.9.0"       | "lesser"  |
-      | "2.0.0-alpha" | "lesser"  |
-      | "2.0.0.0"     | "none"    |
+      | version     | value   |
+      | 2.0.0       | equal   |
+      | 2.1.0       | greater |
+      | 1.9.0       | lesser  |
+      | 2.0.0-alpha | lesser  |
+      | 2.0.0.0     | none    |
 
+  @semver
   Scenario Outline: Semantic version operator semantic comparison
-    When a string flag with key "major-minor-version-flag" is evaluated with default value "fallback"
-    And a context containing a key "version", with value <version>
-    Then the returned value should be <value>
+    Given a String-flag with key "major-minor-version-flag" and a default value "fallback"
+    And a context containing a key "version", with type "String" and with value "<version>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | version | value   |
-      | "3.0.1" | "minor" |
-      | "3.1.0" | "major" |
-      | "4.0.0" | "none"  |
+      | version | value |
+      | 3.0.1   | minor |
+      | 3.1.0   | major |
+      | 4.0.0   | none  |
 
   Scenario Outline: Time-based operations
-    When an integer flag with key "timestamp-flag" is evaluated with default value 0
-    And a context containing a key "time", with value <time>
-    Then the returned value should be <value>
+    Given a Integer-flag with key "timestamp-flag" and a default value "0"
+    And a context containing a key "time", with type "Integer" and with value "<time>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
       | time       | value |
       | 1          | -1    |
       | 4133980802 | 1     |
 
   Scenario Outline: Targeting by targeting key
-    When a string flag with key "targeting-key-flag" is evaluated with default value "fallback"
-    And a context containing a targeting key with value <targeting key>
-    Then the returned value should be <value>
-    Then the returned reason should be <reason>
+    Given a String-flag with key "targeting-key-flag" and a default value "fallback"
+    And a context containing a targeting key with value "<targeting key>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
+    Then the reason should be "<reason>"
     Examples:
-      | targeting key                          | value  | reason            |
-      | "5c3d8535-f81a-4478-a6d3-afaa4d51199e" | "hit"  | "TARGETING_MATCH" |
-      | "f20bd32d-703b-48b6-bc8e-79d53c85134a" | "miss" | "DEFAULT"         |
+      | targeting key                        | value | reason          |
+      | 5c3d8535-f81a-4478-a6d3-afaa4d51199e | hit   | TARGETING_MATCH |
+      | f20bd32d-703b-48b6-bc8e-79d53c85134a | miss  | DEFAULT         |
 
   Scenario Outline: Errors and edge cases
-    When an integer flag with key <key> is evaluated with default value 3
-    Then the returned value should be <value>
+    Given a Integer-flag with key "<key>" and a default value "3"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<value>"
     Examples:
-      | key                                 | value |
-      | "targeting-null-variant-flag"       | 2     |
-      | "error-targeting-flag"              | 3     |
-      | "missing-variant-targeting-flag"    | 3     |
-      | "non-string-variant-targeting-flag" | 2     |
-      | "empty-targeting-flag"              | 1     |
+      | key                                | value |
+      | targeting-null-variant-flag       | 2     |
+      | error-targeting-flag              | 3     |
+      | missing-variant-targeting-flag    | 3     |
+      | non-string-variant-targeting-flag | 2     |
+      | empty-targeting-flag              | 1     |
diff --git a/gherkin/flagd-reconnect.feature b/gherkin/flagd-reconnect.feature
index 463d2bd..434c3bf 100644
--- a/gherkin/flagd-reconnect.feature
+++ b/gherkin/flagd-reconnect.feature
@@ -1,15 +1,18 @@
+@rpc @in-process @reconnect
 Feature: flagd provider disconnect and reconnect functionality
 
   # This test suite tests the reconnection functionality of flagd providers
-
   Scenario: Provider reconnection
-    Given a flagd provider is set
-    When a PROVIDER_READY handler and a PROVIDER_ERROR handler are added
-    Then the PROVIDER_READY handler must run when the provider connects
-    And the PROVIDER_ERROR handler must run when the provider's connection is lost
-    And when the connection is reestablished the PROVIDER_READY handler must run again
+    Given a unstable flagd provider
+    And a ready event handler
+    And a error event handler
+    When a ready event was fired
+    Then the ready event handler should have been executed
+    When a error event was fired
+    Then the error event handler should have been executed
 
   Scenario: Provider unavailable
-    Given flagd is unavailable
-    When a flagd provider is set and initialization is awaited
-    Then an error should be indicated within the configured deadline
+    Given an option "deadlineMs" of type "Integer" with value "1000"
+    And a unavailable flagd provider
+    And a error event handler
+    Then the error event handler should have been executed within 1000ms
diff --git a/gherkin/flagd-rpc-caching.feature b/gherkin/flagd-rpc-caching.feature
index d2aeaea..f124072 100644
--- a/gherkin/flagd-rpc-caching.feature
+++ b/gherkin/flagd-rpc-caching.feature
@@ -1,44 +1,61 @@
+@rpc @caching
 Feature: Flag evaluation with Caching
 
 # This test suite contains scenarios to test the flag evaluation API with caching (RPC only)
-
   Background:
-    Given a provider is registered
-
-  Scenario: Resolves boolean details with caching
-    When a boolean flag with key "boolean-flag" is evaluated with details and default value "false"
-    Then the resolved boolean details value should be "true", the variant should be "on", and the reason should be "STATIC"
-    Then the resolved boolean details value should be "true", the variant should be "on", and the reason should be "CACHED"
-
-  Scenario: Resolves string details with caching
-    When a string flag with key "string-flag" is evaluated with details and default value "bye"
-    Then the resolved string details value should be "hi", the variant should be "greeting", and the reason should be "STATIC"
-    Then the resolved string details value should be "hi", the variant should be "greeting", and the reason should be "CACHED"
-
-  Scenario: Resolves integer details with caching
-    When an integer flag with key "integer-flag" is evaluated with details and default value 1
-    Then the resolved integer details value should be 10, the variant should be "ten", and the reason should be "STATIC"
-    Then the resolved integer details value should be 10, the variant should be "ten", and the reason should be "CACHED"
-
-  Scenario: Resolves float details with caching
-    When a float flag with key "float-flag" is evaluated with details and default value 0.1
-    Then the resolved float details value should be 0.5, the variant should be "half", and the reason should be "STATIC"
-    Then the resolved float details value should be 0.5, the variant should be "half", and the reason should be "CACHED"
-
-  Scenario: Resolves object details with caching
-    When an object flag with key "object-flag" is evaluated with details and a null default value
-    Then the resolved object details value should be contain fields "showImages", "title", and "imagesPerPage", with values "true", "Check out these pics!" and 100, respectively
-    And the variant should be "template", and the reason should be "STATIC"
-    Then the resolved object details value should be contain fields "showImages", "title", and "imagesPerPage", with values "true", "Check out these pics!" and 100, respectively
-    And the variant should be "template", and the reason should be "CACHED"
+    Given an option "cache" of type "CacheType" with value "lru"
+    And a stable flagd provider
+
+  Scenario Outline: Resolves <type> details with caching
+    Given a <type>-flag with key "<key>" and a default value "<default>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<resolved_value>"
+    And the variant should be "<resolved_variant>"
+    And the reason should be "STATIC"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<resolved_value>"
+    And the variant should be "<resolved_variant>"
+    And the reason should be "CACHED"
+
+    Examples:
+      | key          | type    | default | resolved_variant | resolved_value                                                                |
+      | boolean-flag | Boolean | false   | on               | true                                                                          |
+      | string-flag  | String  | bye     | greeting         | hi                                                                            |
+      | integer-flag | Integer | 1       | ten              | 10                                                                            |
+      | float-flag   | Float   | 0.1     | half             | 0.5                                                                           |
+      | object-flag  | Object  | null    | template         | {"showImages": true, "title": "Check out these pics!", "imagesPerPage": 100 } |
 
   Scenario: Flag change event with caching
-    When a string flag with key "changing-flag" is evaluated with details
-    When a PROVIDER_CONFIGURATION_CHANGED handler is added
-    And a flag with key "changing-flag" is modified
-    Then the returned reason should be "STATIC"
-    Then the returned reason should be "CACHED"
-    Then the PROVIDER_CONFIGURATION_CHANGED handler must run
-    And the event details must indicate "changing-flag" was altered
-    Then the returned reason should be "STATIC"
-    Then the returned reason should be "CACHED"
+    Given a String-flag with key "changing-flag" and a default value "false"
+    And a change event handler
+    When a change event was fired
+    And the flag was modified
+    And the flag was evaluated with details
+    Then the reason should be "STATIC"
+    When the flag was evaluated with details
+    Then the reason should be "CACHED"
+    When a change event was fired
+    And the flag was modified
+    And the flag was evaluated with details
+    Then the reason should be "STATIC"
+    When the flag was evaluated with details
+    Then the reason should be "CACHED"
+
+  Scenario: Stale and Error stage
+    Given an option "cache" of type "CacheType" with value "lru"
+    And a unstable flagd provider
+    And a ready event handler
+    And a stale event handler
+    And a error event handler
+    And a String-flag with key "changing-flag" and a default value "false"
+    When the flag was evaluated with details
+    Then the reason should be "STATIC"
+    When the flag was evaluated with details
+    Then the reason should be "CACHED"
+    When a stale event was fired
+    And the flag was evaluated with details
+    Then the reason should be "CACHED"
+    When a error event was fired
+    And a ready event was fired
+    And the flag was evaluated with details
+    Then the reason should be "STATIC""
diff --git a/gherkin/flagd.feature b/gherkin/flagd.feature
index 85490bd..4b2ee10 100644
--- a/gherkin/flagd.feature
+++ b/gherkin/flagd.feature
@@ -1,3 +1,4 @@
+@rpc @in-process
 Feature: flagd providers
 
   # This test suite contains scenarios to test flagd providers.
@@ -5,32 +6,29 @@ Feature: flagd providers
   # It should be used in conjunction with the suites supplied by the OpenFeature specification.
 
   Background:
-    Given a flagd provider is set
+    Given an option "cache" of type "CacheType" with value "disabled"
+    And a stable flagd provider
 
   # events
   Scenario: Provider ready event
-    When a PROVIDER_READY handler is added
-    Then the PROVIDER_READY handler must run
+    Given a ready event handler
+    Then the ready event handler should have been executed
 
   Scenario: Flag change event
-    When a PROVIDER_CONFIGURATION_CHANGED handler is added
-    And a flag with key "changing-flag" is modified
-    Then the PROVIDER_CONFIGURATION_CHANGED handler must run
-    And the event details must indicate "changing-flag" was altered
-
-  # zero evaluation
-  Scenario: Resolves boolean zero value
-    When a zero-value boolean flag with key "boolean-zero-flag" is evaluated with default value "true"
-    Then the resolved boolean zero-value should be "false"
-
-  Scenario: Resolves string zero value
-    When a zero-value string flag with key "string-zero-flag" is evaluated with default value "hi"
-    Then the resolved string zero-value should be ""
-
-  Scenario: Resolves integer zero value
-    When a zero-value integer flag with key "integer-zero-flag" is evaluated with default value 1
-    Then the resolved integer zero-value should be 0
-
-  Scenario: Resolves float zero value
-    When a zero-value float flag with key "float-zero-flag" is evaluated with default value 0.1
-    Then the resolved float zero-value should be 0.0
+    Given a String-flag with key "changing-flag" and a default value "false"
+    And a change event handler
+    When a change event was fired
+    Then the change event handler should have been executed
+    And the flag was modified
+
+  Scenario Outline: Resolves zero value
+    Given a <type>-flag with key "<key>" and a default value "<default>"
+    When the flag was evaluated with details
+    Then the resolved details value should be "<resolved_value>"
+
+    Examples:
+      | key               | type    | default | resolved_value |
+      | boolean-zero-flag | Boolean | true    | false          |
+      | string-zero-flag  | String  | hi      |                |
+      | integer-zero-flag | Integer | 1       | 0              |
+      | float-zero-flag   | Float   | 0.1     | 0.0            |