Add ability to pass in custom values via config #55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cruikshanks
force-pushed
the
feature/custom-config
branch
from
ef49baf to
409c953
Compare
Currently the config Quke exposes is for controlling how it runs and behaves. However feedback has shown that projects based on Quke often require their own configuration values. A common example is usernames and passwords for accounts when testing features that require authentication. Now there are options for dealing with this; setting environment variables and then reading them in within the project being the most obvious solution. You could even write your own configuration mechanism if you had the necessary skills. However Quke is specifically targeted at team members who may not have development backgrounds, and therefore aims to make creating acceptance tests as simple as possible. For this reason, and from speaking with current users we have chosen to extend the existing configuration functionality in Quke to allow users to add their own custom values, which they can then access from the Quke config class within their projects. This means users only have to think about one source for all the configuration within their projects, the `.config.yml` file. This change adds a new method to `Quke::Configuration` called `custom()`, which returns whatever values have been set under a root node called `custom` in the `.config.yml` file. Being YAML, this could be simple key value pairs, or a whole new object in itself. We have also expanded the section on configuration in the README.md to cover this, providing examples of the things you can add and how to access them from your projects.
Cruikshanks
force-pushed
the
feature/custom-config
branch
from
409c953 to
de10654
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently the config Quke exposes is for controlling how it runs and behaves. However feedback has shown that projects based on Quke often require their own configuration values. A common example is usernames and passwords for accounts when testing features that require authentication.
Now there are options for dealing with this; setting environment variables and then reading them in within the project being the most obvious solution. You could even write your own configuration mechanism if you had the necessary skills.
However Quke is specifically targeted at team members who may not have development backgrounds, and therefore aims to make creating acceptance tests as simple as possible.
For this reason, and from speaking with current users we have chosen to extend the existing configuration functionality in Quke to allow users to add their own custom values, which they can then access from the Quke config class within their projects. This means users only have to think about one source for all the configuration within their projects, the
.config.ymlfile.This change adds a new method to
Quke::Configurationcalledcustom(), which returns whatever values have been set under a root node calledcustomin the.config.ymlfile. Being YAML, this could be simple key value pairs, or a whole new object in itself.We have also expanded the section on configuration in the README.md to cover this, providing examples of the things you can add and how to access them from your projects.