The access_website stack runs the services that actually provide the end-user website for https://www.webarchive.org.uk/ or https://beta.webarchive.org.uk/ or https://dev.webarchive.org.uk.
A series of tests for the website are held under the tests folder. As well as checking service features and critical APIs, these test also cover features relating legal compliance.
The tests are defined as Robot Framework acceptance tests. In the tests/robot/tests we have a set of .robot files that define tests for each major web site feature (e.g. Wayback). The tests are written in an pseudo-natural-language tabular format, relying heavily on web testing automation keywords provided by the Robot Framework Selenium Library.
Here's an example of a simple test sequence...
Open Browser
Open Browser To Home Page
Check Wayback EN Home Page
[Tags] wayback locale en
Go To %{HOST}/wayback/en
Page Should Contain UK Web Archive Access System
The first test (Open Browser) uses the Open Browser To Home Page keyword, which we've defined in the shared _resource.robot file. This sets up the right test browser with the right configuration for the tests in this file (when developing tests, take care to ensure that Open Browser is only called once per test file. It tends to hang if it's called multiple times). The next test (Check Wayback EN Home Page) loads the English-language Wayback homepage and checks the page contains a particular text string (n.b. matching is case-sensitive).
This provides a simple language for describing the expected behaviour of the site, and makes it easy to add further tests. By putting the host name in an environment variable (referenced as %{HOST}), we can run the same test sequence across HOST=https://www.webarchive.org.uk, HOST=https://beta.webarchive.org.uk or even HOST=https://username:[email protected].
The deployment script can be run like this:
cd website_tests
./deploy-website-tests.sh dev
The script handles setting up the HOST based on the deployment context.
The stack will spin up the necessary Selenium containers (with the Selenium Hub exposed on port 4444 in case you want to take a look), and then run the tests. The results will be visible in summary in the console, and in detail via the results/report.html report file. If you hit errors, the system should automatically take screenshots so you can see what the browser looked like at the point the error occured.
The tests are run once on startup, and results are posted to Prometheus. Following test runs can be orchestrated by using cron to run:
docker service update --force access_website_tests_robot
These can be run each morning, and the metrics posted to Prometheus used to track compliance and raise alerts if needed.
There are two Reading Room services, the current (legacy) one and the newer one created by the Legal Deposit Access Solution project.
The new one has detailed documentation in a dedicated repository: https://github.com/ukwa/npld-access-stack#readme
The old one is very old, and is a manually-installed set of services based on OpenWayback. It is not documented further here.