test: add Gherkin evaluator tests using test-harness specs

[aepfli]

Summary

• Adds in-process Gherkin (BDD) tests for the JSON evaluator using godog and the shared test-harness/evaluator/ feature specs
• Tests run directly against the evaluator without testcontainers, validating: flag evaluation, error handling, targeting, metadata, fractional bucketing (v2), semver, string operators, zero-values, evaluator refs, and no-default-variant behavior
• 83 scenarios pass, @fractional-v1 excluded (flagd implements v2)
• Adds test-evaluator-gherkin Makefile target

Related: open-feature/python-sdk-contrib#377 (equivalent Python testkit)
Part of: open-feature/flagd-testbed#366 (centralized evaluator testkit migration)
See also: open-feature/flagd-testbed#367 (error handling discussion)

Test plan

• make test-evaluator-gherkin passes all 83 scenarios
• Existing unit tests unaffected (go test -short ./core/pkg/evaluator/...)
• CI passes

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for polite-licorice-3db33c canceled.

Name	Link
🔨 Latest commit	d43c66e
🔍 Latest deploy log	https://app.netlify.com/projects/polite-licorice-3db33c/deploys/69e089461ac7c800088b5427

[gemini-code-assist]

Code Review

This pull request introduces Gherkin-based integration tests for the evaluator component. It adds a new test file core/pkg/evaluator/gherkin_test.go utilizing the godog framework to execute feature-based tests against the evaluator's logic, including support for various data types, targeting keys, and metadata assertions. Additionally, the Makefile has been updated with a test-evaluator-gherkin target, and necessary dependencies have been added to core/go.mod. I have no feedback to provide.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[toddbaert]

@aepfli Nice.

I don't think this is really a feat for end-users. I think let's make it a chore/test?

Also - should we run it in the CI?

[aepfli]

I agree with the pr title, and changed it

Also - should we run it in the CI?

Maybe my knowledge is off, but we do not have the e2e tag, so this should execute with normal test execution, or am i wrong here? as it does not need docker, etc. it should be fast, and there is no reason to not run it during normal test execution.

[toddbaert]

I agree with the pr title, and changed it

Also - should we run it in the CI?

Maybe my knowledge is off, but we do not have the e2e tag, so this should execute with normal test execution, or am i wrong here? as it does not need docker, etc. it should be fast, and there is no reason to not run it during normal test execution.

I don't think it's running. The submodule doesn't seem to be checked out in the CI and the coverage is exactly the same.