Testing (Quick-Start Guide)
Until the documentation is in full effect, it's recommended that a GraphiQL-based tool like WPGraphQL IDE be used to view the GraphQL schema, an alternative to this is viewing the unit tests located in
tests/wpunit directory. Which are constantly updated along with the project. If you're interested in contributing when I begin accepting contribution or simply want to run the tests. Follow the instruction below.
First copy the
.envand alter to make you usage.# WordPress admin configurationsADMIN_EMAILfirstname.lastname@example.orgADMIN_USERNAME=adminADMIN_PASSWORD=passwordADMIN_PATH=/wp-admin# WordPress local configurationsWP_CORE_DIR=local/publicPLUGINS_DIR=local/public/wp-content/pluginsMUPLUGINS_DIR=local/public/wp-content/mu-pluginsTHEMES_DIR=local/public/wp-content/themes# WordPress database configurationsDB_NAME=wordpressDB_HOST=app_dbDB_PORT=3306DB_USER=wordpressDB_PASSWORD=passwordROOT_PASSWORD=passwordWP_TABLE_PREFIX=wp_SKIP_DB_CREATE=false# Extra variables/constants.GRAPHQL_JWT_AUTH_SECRET_KEY=testingtesting123STRIPE_API_PUBLISHABLE_KEY=""STRIPE_API_SECRET_KEY=""PHPUNIT_VERSION=":<=9.4.4"
- Typical you should only have to change the WordPress database configurations to use local testing.
- Once you have finished modifying the
composer install-test-envfrom the project directory. This will install WordPress + Codeception w/ WPBrowser, as well as setup the database if needed.
- Upon success you can begin running the tests.
Running Tests Locally
To run the tests use the command
vendor/bin/codecept run [suite [test [:test-function]]].
If you use the command with at least a
suite specified, Codeception will run all tests, however this is not recommended. Running a suite
vendor/bin/codecept run wpunit or a test
vendor/bin/codecept run CouponQueriesTest is recommended. Running a single
vendor/bin/codecept run ProductQueriesTest:testProductsQueryAndWhereArgs is also possible.
To learn more about the usage of Codeception with WordPress view the Documentation
Functional and Acceptance Tests (Server or Docker Required)
Running functional and acceptance tests requires that WordPress installation being used for testing be accessible thru some kind of URL/Address and then setting that URL/Address in the codeception.dist.yml file or in the .env file as WORDPRESS_DOMAIN/WORDPRESS_URL.
Note: The codeception.dist.yml should be left unchanged and a copy named codeception.yml should be used.
install-test-env alone does not configure a server to point at the Wordpress installation it creates, you're two options for doing this.
- Configure an Apache or Nginx server block and point it at the WordPress installation created by the
install-test-envscript. This isn't a very flexible or quick method.
- Use the Docker configurations in the project to push the installation into a docker network and expose it's docker container's IP as the URL/Address. This is the recommended option if Docker/Docker-Compose is available to you. The project includes some simple composer scripts that enable you to run all at once or filter specific tests for speed, test isolation, or XDebug Stepping Debug.
The composer scripts for using dockers are.
docker-buildbuilds this the Docker Image for the
woographql/wordpresscontainer that will house the WordPress installation and tests.
docker-run-appspins up the docker network. This can be used for live debug as well as cli test. The WordPress installation will be accessible from a URL provided in the
woographql/wordpresscontainer log in you terminal.
docker-run-testing-dbadd a cloned MySQL instance of the one created in
docker-run-appfor testing, this is to be run after the docker network as been created using
docker-run-appand before the tests are run inside of the
woographql/wordpresscontainer. Note: This should not be used directly. See
docker-set-main-dbconfigures the wp-config.php of wordpress installation to point at the main MySQL container. This is for returning to live development using the browser after running the tests in cli.
docker-set-testing-dbis essentially the same
docker-set-main-dbjust for the testing database. However this script stalls and looks for the testing database to be available. Note: This should not be used directly. See
docker-run-testis the primary tester script and the script you'll probably call the most. This script essentially just runs
codecept run $FILTERin the
woographql/wordpress, however before that it runs
docker-set-testing-dbto ensure all the need players are set.
FILTERis a shell variable that can be what parameter you what to pass to the run command except the
--no-exitoptions. For usage see this example.
FILTER="wpunit CartMutationsTest:testAddToCartMutationWithProduct --debug" composer docker-run-test
docker-run-test-standalonesetups the docker network, run all the tests, and pulls down the network. Primarily for CI.
Running Tests with Docker/Docker-Compose
Running the tests in rather simple, but you may need two terminal windows depending on you method.
- (Requires two terminals in the project root directory) In one terminal run
composer docker-build && composer docker-run-app. Wait until you see the log
testable_app_x_xxxxxxxxxxxx | WordPress app located at http://xxx.xxx.xxx.xxx, then you're ready to run the tests and can leave this terminal running and move to your second one. In your second terminal you can run the by executing
composer run-testThis will run all the tests at once with no options passed to the
codecept runcommand. This can be alter with
FILTERvariable mention in the last section. The first time you run this command it will be delayed due to having to setup the test database. Also one last thing to note is if you when to switch to live development/debugging in the browser have running the test this way. Run
composer docker-set-main-dbbefore you do.
- This other method is even alot more streamline and only needs one command
composer docker-run-test-standalone. See description of what it does in the last section.
Using Docker-Compose to Run a Local Installation for Live Testing
This is rather simple just like with testing using docker ensure that
codeception.dist.yml are untouched.
composer docker-build && composer docker-run-app.
- Wait until you see the log
testable_app_x_xxxxxxxxxxxx | WordPress app located at http://xxx.xxx.xxx.xxx.
- Navigate to the provided address.