This repository provides some automated integration testing for the Raygun4WP provider.

Requires Docker

1. Create a Raygun application and insert your API key into settings.env.
2. Choose whether to target a specific branch of the provider repository or to use the distributed version in settings.env.
3. If needed, use docker compose --profile update up to automatically update the provider submodule from the branch specified.
4. Use docker compose --profile test up to run testing on the Raygun4WP provider! Be sure to run docker 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 in settings.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.