feat: enhance evaluation context Gherkin tests with comprehensive spec coverage

[aepfli]

Expand contextMerging.feature to provide complete behavioral coverage of the 03-evaluation-context.md specification and rename to evaluation_context.feature to better reflect its comprehensive scope.

Key Enhancements

File Rename

• Renamed contextMerging.feature → evaluation_context.feature
• Better reflects comprehensive evaluation context coverage beyond just merging

Unified Type-Aware Step Definitions

• Standardized all context assertions to use unified pattern: The merged context contains an entry with key "<key>" and value "<value>" of type "<type>"
• Added explicit type validation to all existing context merging scenarios
• Consolidated type checking into single, reusable step definition
• Updated Given steps to include type specification for consistency

Comprehensive Behavioral Coverage

Added test scenarios for previously uncovered evaluation context requirements:

Context Field Requirements (3.1.x):

• 3.1.1: Optional targeting key field validation and optional nature
• 3.1.2: Custom field type support (boolean, string, integer)
• 3.1.3: Field access methods demonstrating retrieval capabilities
• 3.1.4: Unique key enforcement through context precedence rules

Enhanced Context Merging (3.2.3):

• Added comprehensive tagging and specification references
• Improved scenario descriptions for clarity
• Maintained full precedence testing: API → Transaction → Client → Invocation → Before Hooks

Implementation Optimizations

• Maximized reuse of existing step definitions to minimize implementation overhead
• Leveraged context merging precedence to demonstrate key uniqueness (3.1.4)
• Used practical type mappings compatible with Java implementation:
  • number → integer for better type system compatibility
  • Focused on commonly implemented types (boolean, string, integer)
• Removed redundant API availability tests in favor of behavioral validation

Implicit Coverage Documentation

Added comprehensive documentation explaining why certain specification requirements don't need dedicated test scenarios:

Context Paradigms (3.2.1.1, 3.2.2.1-2.4, 3.2.4.1-4.2):

• Dynamic/static paradigm method availability proven by successful context merging
• Domain-specific context and change notifications are provider-level concerns
• Architectural decisions don't require behavioral validation

Context Propagation (3.3.1.1, 3.3.1.2.1-2.3, 3.3.2.1):

• Transaction propagator management is API design, not behavior
• Transaction context behavior already validated by @transaction merging tests
• Implementation-specific propagation mechanisms vary by language/platform

Enhanced Test Organization

• Comprehensive tagging for selective test execution:
  • @context-fields, @context-merging, @context-precedence
  • @targeting-key, @custom-fields, @field-access, @unique-keys
  • Specification tags: @spec-3.1.1 through @spec-3.2.3
• Logical grouping of related scenarios
• Clear separation between behavioral tests and implicit coverage

Breaking Changes

• File renamed: contextMerging.feature → evaluation_context.feature
• Modified all existing context assertion steps to include type specification
• Context paradigm and propagation scenarios removed (documented as implicit)
• Requires step definition updates to handle of type "<type>" parameter

Testing Strategy

The enhanced test suite validates core evaluation context behavior:

1. Context Merging: Precedence rules across all context levels
2. Type Safety: Explicit type validation for all context values
3. Field Management: Custom fields, targeting keys, and key uniqueness
4. Practical Coverage: Focus on implementable, testable behaviors

This provides comprehensive validation of evaluation context functionality while eliminating redundant API availability tests and focusing on behavioral requirements that implementation teams actually need to validate.

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @aepfli, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the Gherkin test suite for evaluation context. It expands the test coverage to align comprehensively with the 03-evaluation-context.md specification, ensuring robust validation of context field requirements, merging precedence, and type safety. The changes also improve test organization and clarity by renaming the feature file, standardizing step definitions, and explicitly documenting implicitly covered specification points.

Highlights

• File Renaming and Scope Expansion: The contextMerging.feature file has been renamed to evaluation_context.feature to better reflect its expanded scope beyond just context merging, now covering comprehensive evaluation context.
• Unified Type-Aware Step Definitions: All context assertion steps now include explicit type validation (e.g., of type ""), standardizing the pattern and consolidating type checking.
• Comprehensive Behavioral Coverage: New test scenarios have been added to cover previously uncovered evaluation context requirements from the specification (sections 3.1.1, 3.1.2, 3.1.3, 3.1.4, and enhanced 3.2.3).
• Optimized Implementation and Test Organization: The changes maximize reuse of existing step definitions, leverage context merging precedence for key uniqueness, and introduce comprehensive tagging for selective test execution and logical grouping of scenarios.
• Breaking Changes: Existing context assertion steps require updates to handle the new type specification parameter, and some context paradigm and propagation scenarios have been removed as they are now implicitly covered.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This is an excellent enhancement to the Gherkin test suite for evaluation context. Renaming contextMerging.feature to evaluation_context.feature and expanding it to cover the specification more comprehensively is a great improvement. The addition of explicit type checking, new scenarios for context fields, and detailed tagging significantly increases the clarity and value of these tests. I especially appreciate the detailed comments explaining which parts of the spec are considered implicitly covered. I have one suggestion to make one of the test scenarios even more concise and robust.

[gemini-code-assist]

This scenario is intended to test spec 3.1.3, which requires support for fetching fields by key and fetching all key-value pairs. While the current Then steps do verify fetching by key, they are a bit verbose and don't explicitly test the "fetch all" capability.

To make the test more concise and better align with the spec, consider using a single Then step with a data table to verify all the expected entries in the merged context. This would require a new step definition but would make the scenario clearer and more robust.

For example:

Then the merged context contains the following entries:
  | key        | value    | type    |
  | user_name  | John Doe | string  |
  | user_age   | 30       | integer |
  | is_premium | true     | boolean |

    Then the merged context contains the following entries:
      | key        | value    | type    |
      | user_name  | John Doe | string  |
      | user_age   | 30       | integer |
      | is_premium | true     | boolean |

[aepfli]

yes i will add this - sounds like a valuable addition