Description
Our Gherkin test helps us; it provides great flexibility, but in each language, we need to provide a lot of tedious setup and configuration, such as what to run, for which provider, etc.
With the new Config steps, we could be more flexible, trim our features to be more dedicated, and tag them correctly.
example
Currently, we have one flagd-evaluation.feature
file and load this manually based on different configurations within our tests. Additionally, we have a flagd-reconnect.feature
file, which we load with a different docker image.
Due to that, we only have one file for each scenario, which is neat. However, we still set them up in separate test files, which ends up being four different test files for two features with two different Docker images.
Our background looks the same all the time:
Background:
Given a flagd provider is set
proposal
As we are now using the same Docker image for in-process
and for rpc,
we could start both images with different ports and adapt the background.
Background:
Given a (stable|unstable|unavailable) flagd provider
We can execute just one Gherkin test per resolver, reducing our test files and setups.
additional information
Furthermore, we're currently more flexible, as we can utilize the Config-Steps to modify what we're loading with a provider. E.g. if we do not use the background, the tests always need a different provider.
Background:
Given an option "keepAliveTime" of type "Long" with value "400"
And a (stable|unstable|unavailable) flagd provider
Questions
- do you think this sounds like a good idea, should we adapt our logic to this?
Activity