This repository provides some automated integration testing for the Raygun4WP provider.
Requires Docker
- Create a Raygun application and insert your API key into
settings.env
. - Choose whether to target a specific branch of the provider repository or to use the distributed version in
settings.env
. - If needed, use
docker compose --profile update up
to automatically update the provider submodule from the branch specified. - Use
docker compose --profile test up
to run testing on the Raygun4WP provider! Be sure to rundocker compose --profile test down
in between tests. It may also be necessary to use--force-recreate
when composing.
After the automated server-side testing has completed, you will be prompted to visit the site in your browser. Complete the client-side testing by clicking each of the buttons displayed. Finally, compare your results (now located in the Raygun app) with the expected results below.
- If you intend to test the shutdown handler (crash with fatal error), you may use
crash
mode insettings.env
. - If you need to test against a specific version of WordPress, this can be specified in
docker-compose.yml
line 35. - If you would like to enable WordPress debug logging, this option can be set in
docker-compose.yml
line 23.
These 9 unique errors should appear, 4 of which should have 2 occurances (highlighted):
Inspecting any error should show the user "test" (@raygun.com):
Adding a tag filter for "serverside" (Add filter → Tags → is one of)...
Should yield these 5 unique errors.
Adding a tag filter for "clientside"...
Should yield these 3 unique errors.
Further inspecting one of these client-side errors (e.g. "Manually sent error") should reveal breadcrumbs such as:
Inspecting the test session...
Should display these two page views and appropriate information:
If you intend to make changes, running docker compose --profile clean up
removes the API key from settings.env (functionality can be extended in clean.sh
).
This plugin is activated alongside the raygun4wp provider plugin that is to be tested. It adds an additional admin menu page (test_page
) that can be posted to externally (e.g. from run_tests.sh
). Any request to this page is checked for a 'test'
parameter. This parameter expects a string that corresponds to a testing function in tests.php
, which will be subsequently executed. This means that adding a new test is as simple as adding a function to tests.php
and posting to the test_page
with the new test string.
The test page also contains a JavaScript component for client-side testing. This JavaScript code is to be executed by the tester's browser when they request the page.
This script first prepares the testing environment by installing WordPress Core, copying in/installing the necessary plugins, activating them, and performing the admin login for the client. It is then able to run both "external tests" as a client (meaning tests that do not require new PHP code to be executed on the server) and server-side tests by posting to the test_page
as described above. It includes the function run-serverside-test()
for this very purpose, as well as assert-equals()
for basic validation.