Although this technique allows for some level of composition it does not actually allow for custom parameter configurations to be passed into the default context configuration. This state is problematic because we cannot easily adjust the behavior of a dkan test against custom context configurations.
So we need a way to pass custom parameters into the default context.
As far as I can tell, Behat does not provide a way to do this in a clean fashion (i.e. that does not involve us updating the dkan/test/behat.yml file directly with our custom params). However updating this file manually will be prone to mistakes as any updates we make will be removed automatically and we will need to remember to re add them. We could potentially use a custom patch to automatically re apply our changes on upgrades. But patches will be potentially brittle as changes are made to the dkan/test/behat.yml file in the upstream repo.
A better approach would be to introduce a build step that can merge our custom parameters into the the default behat.yml file in a similar fashion to the way we now merge the upstream config/config.yml to the site specific config/cofig.yml file.
The question then remains, where should we store these custom params? There are two obvious places in my opinion, both with pros and cons:
Either these custom params should live in config/config.yml or they should live in config/tests/behat.custom.yml.
In my opinion they should go intoconfig/config.yml since we already use this file as a database for custom default settings that then get applied in different contexts across the entire dkan_starter build cycle. However, I do acknowledge that to the uninitiated, that location may not seem obvious. But that limitation can be easily corrected with proper documentation. And at least using config/config.yml establishes a consistent way of storing and applying custom configurations.
Acceptance Criteria
[x] ahoy build config should now apply any custom parameters set in the config/cofig.yml into the dkan/test/behat.yml context configuration.
dkinzer
commented
7 years ago
Description
Currently we use profile and suite level controls to combine our default and custom behat configuration as described here: https://github.com/NuCivic/dkan_starter/blob/master/docs/docker-dev-env/behat-setup.rst
Although this technique allows for some level of composition it does not actually allow for custom parameter configurations to be passed into the default context configuration. This state is problematic because we cannot easily adjust the behavior of a dkan test against custom context configurations.
So we need a way to pass custom parameters into the default context.
As far as I can tell, Behat does not provide a way to do this in a clean fashion (i.e. that does not involve us updating the
dkan/test/behat.ymlfile directly with our custom params). However updating this file manually will be prone to mistakes as any updates we make will be removed automatically and we will need to remember to re add them. We could potentially use a custom patch to automatically re apply our changes on upgrades. But patches will be potentially brittle as changes are made to thedkan/test/behat.ymlfile in the upstream repo.A better approach would be to introduce a build step that can merge our custom parameters into the the default behat.yml file in a similar fashion to the way we now merge the upstream
config/config.ymlto the site specificconfig/cofig.ymlfile.The question then remains, where should we store these custom params? There are two obvious places in my opinion, both with pros and cons:
Either these custom params should live in
config/config.ymlor they should live inconfig/tests/behat.custom.yml.In my opinion they should go into
config/config.ymlsince we already use this file as a database for custom default settings that then get applied in different contexts across the entire dkan_starter build cycle. However, I do acknowledge that to the uninitiated, that location may not seem obvious. But that limitation can be easily corrected with proper documentation. And at least usingconfig/config.ymlestablishes a consistent way of storing and applying custom configurations.Acceptance Criteria
ahoy build configshould now apply any custom parameters set in theconfig/cofig.ymlinto thedkan/test/behat.ymlcontext configuration.