You may need an environmental permit if you want to work in, over, under or near a main river or flood or sea defence. Some flood risk activities are exempt from needing a permit and you can carry out the work if you register an exemption.
Register a flood risk activity exemption is the digital service which allows users to register an exemption.
This project contains the acceptance tests for the service. It is built around Quke, a Ruby gem that simplifies the process of writing and running Cucumber acceptance tests.
This project is setup to run against version 3.2.2 of Ruby.
The rest of the pre-requisites are the same as those for Quke.
First clone the repository and then drop into your new local repo
git clone https://github.com/DEFRA/flood-risk-acceptance-tests.git && cd flood-risk-acceptance-testsNext download and install the dependencies
bundle installYou can figure how the project runs using Quke config files.
Quke relies on yaml files to configure how the tests are run, the default being .config.yml.
If left as that by default when Quke is executed it will run against your selected environment using Chrome.
Simply call
bundle exec qukeYou can create multiple config files, for example you may wish to have one setup for running against Chrome, and another to run against a different environment. You can tell Quke which config file to use by adding an environment variable argument to the command.
QUKE_CONFIG='chrome.config.yml' bundle exec qukeWithin this project a series of Rake tasks have been added. Each rake task is configured to run one of the configuration files already setup. To see the list of available commands run
bundle exec rake -TYou can then run your chosen configuration e.g. bundle exec rake tst
Cucumber has an inbuilt feature called tags.
These can be added to a feature or individual scenarios.
@functional
Feature: Validations within the digital service@frontoffice @happypath
Scenario: Registration by an individualWhen applied you then have the ability to filter which tests will be used during any given run
bundle exec quke --tags @frontoffice # Run only things tagged with this
bundle exec quke --tags @frontoffice,@happypath # Run all things with these tags
bundle exec quke --tags ~@functional # Don't run anything with this tag (run everything else)To have consistency across the project the following tags are defined and should be used in the following ways:
| Tag | Description |
|---|---|
| @frontoffice | Any feature or scenario expected to be run against the front office application |
| @backoffice | Any feature or scenario expected to be run against the back office application |
| @happypath | A scenario which details a complete registration with no errors |
| @functional | Any feature or scenario which is testing just a specific function of the service e.g. validation errors |
| @fix | A feature or scenario that highlights an error or issue with the service that needs to be fixed |
| @ci | A feature that is intended to be run only on our continuous integration service (you should never need to use this tag). |
It's also common practice to use a custom tag whilst working on a new feature or scenario e.g. @focus or @wip. That is perfectly acceptable but please ensure they are removed before your change is merged.
This repository includes the ability to check the currently loaded page for accessibility violations. It uses axe-core-capybara and axe-core-cucumber.
To call it, use the following step:
Then the page should be axe clean
# or call this within another step using
step("the page should be axe clean")This calls all of Axe's accessibility rules and is useful to find best practice. However, our minimum standard is to focus on Web Content Accessibility Guidelines v2.1 to levels A and AA, so we want the tests to pass if so. Use this step to reduce the scope:
Then the page should be axe clean according to: wcag21a, wcag21aaAlso refer to Axe API documentation for more detail.
Finally, remember that automated testing is not a substitute for manual testing.
If you have an idea you'd like to contribute please log an issue.
All contributions should be submitted via a pull request.
THIS INFORMATION IS LICENSED UNDER THE CONDITIONS OF THE OPEN GOVERNMENT LICENCE found at:
http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3
The following attribution statement MUST be cited in your products and applications when using this information.
Contains public sector information licensed under the Open Government license v3
The Open Government Licence (OGL) was developed by the Controller of Her Majesty's Stationery Office (HMSO) to enable information providers in the public sector to license the use and re-use of their information under a common open licence.
It is designed to encourage use and re-use of information freely and flexibly, with only a few conditions.