-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cucumber integration tests #70
Conversation
Codecov Report
@@ Coverage Diff @@
## main #70 +/- ##
=======================================
Coverage 96.17% 96.17%
=======================================
Files 9 9
Lines 445 445
Branches 57 57
=======================================
Hits 428 428
Misses 17 17 Continue to review full report at Codecov.
|
Feature: Flag evaluation | ||
|
||
Scenario: Resolves boolean value | ||
Given A boolean flag called boolean-flag with value true exists | ||
When Flag is evaluated with default value false | ||
Then The resolved value should match the flag value | ||
|
||
Scenario: Resolves string value | ||
Given A string flag called string-flag with value #CC0000 exists | ||
When Flag is evaluated with default value #0000CC | ||
Then The resolved value should match the flag value | ||
|
||
Scenario: Resolves number value | ||
Given A number flag called number-flag with value 1 exists | ||
When Flag is evaluated with default value 2 | ||
Then The resolved value should match the flag value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This cannot reside here long term, it has to be in some common repo, and probably included as a submodule. It could be parsed out of the spec, or committed here
// get a client (flagd provider registered in setup) | ||
const client = OpenFeature.getClient(); | ||
|
||
defineFeature(feature, (test) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests are associated with the gerkin. If any test descriptions don't line up with the gerkin clauses, the test fails.
Then The resolved value should match the flag value | ||
|
||
Scenario: Resolves string value | ||
Given A string flag called string-flag with value #CC0000 exists |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These plain-text statements are parsed by our jest-gerkin tests. It works similarly in other languages (Java, Go, dotnet)
services: | ||
flagd: | ||
image: ghcr.io/open-feature/flagd-testbed:latest | ||
ports: | ||
- 8080:8080 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runs the custom flagd image in CI
Signed-off-by: Todd Baert <[email protected]>
This was implemented in another PR |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR adds a PoC for a cross-language integration test suite. The suite works by running a flagd image with an extra layer of config.
Specifically, the PR:
My main question is where this gerkin should reside... It could be in the test harness repo, or it could even be embedded in the spec and parsed out by our spec parser.