5a11d9e064
This commit fixes some inconsistencies in the settings pages, and makes all the existing pages extensible by adding new sections (that was possible in some pages, but not in others). Main changes: 1. Modify the 'get_sections' method so that it invokes a new protected 'get_own_sections' method and then triggers the 'woocommerce_get_sections_' . id filter. This way the filter is triggered only in the base class and not in each of the derived classes too. 2. Change the get_settings() method so that it has its signature changed to get_settings( $current_section = '' ) in the base class and in all the derived class. Some derived classes were already using this signature, but others (those not having multiple sections natively) weren't, making then effectively impossible to define multiple sections for these pages via filters. With this change all the section pages act consistently and allow both adding new settings to the default "General" section and creating new sections via filters. 3. Change the implementation of 'get_settings' in the base class so that it searches for a 'get_settings_for_{section_id}_section' method in the class and executes it, otherwise it executes the new protected method get_settings_for_section( $current_section ); then it triggers the 'woocommerce_get_settings_' . id filter. This makes it easier to separate the code that returns the list of filters in multiple methods, one per section, instead of using one big if-else-else... block. So now instead of overriding get_settings($current_section='') derived classes need to implement get_settings_for_{$current_section}_section for each section, or override get_settings_for_section($current_section) or both. 'get_settings_for_section' returns an empty array by default. Also, 'woocommerce_get_settings_' . id is triggered in one single place too. Other improvements: * Remove duplicated code from 'output' in 'WC_Settings_Page' children. Some classes inherited from 'WC_Settings_Page' override the 'output' method with custom code, which in all cases ended up repeating the code of the original method as a fallback. These repetitions have been replaced with 'parent::output()'. * Fix inconsistencies for 'save' and 'output' in WC_Settings_Tax/Emails The 'WC_Settings_Tax' and 'WC_Settings_Emails' classes had some inconsistencies in their 'save' and 'output' methods that prevented the proper creation new sections and the addition of new settings via the 'woocommerce_get_sections_' and 'woocommerce_get_settings_' filters. Now they work as expected. * Deduplicate parts of 'save' in 'WC_Settings_Page' and children. Two methods have been added to 'WC_Settings_Page' class: 'save_settings_for_current_section' and 'do_update_options_action'. These are intended to be invoked by derived classes in their 'save' methods, in order to remove code repetition. * Add some helper methods to WC_Unit_Test_Case. Methods added: - assertOutputsHTML - assertEqualsHTML - normalize_html - capture_output_from |
||
---|---|---|
.. | ||
Tools | ||
bin | ||
cli | ||
e2e | ||
legacy | ||
php | ||
unit-tests | ||
README.md |
README.md
WooCommerce Tests
This document discusses unit tests. See the e2e README to learn how to setup testing environment for running e2e tests and run them.
Table of contents
Initial Setup
MySQL database
To run the tests, you need to create a test database. You can:
- Access a database on a server
- Connect to your local database on your machine
- Use a solution like VVV - if you are using VVV you might need to
vagrant ssh
first - Run a throwaway database in docker with this one-liner:
docker run --rm --name woocommerce_test_db -p 3306:3306 -e MYSQL_ROOT_PASSWORD=woocommerce_test_password -d mysql:5.7.33
. ( Usetests/bin/install.sh woocommerce_tests root woocommerce_test_password 0.0.0.0
in next step)
Setup instructions
Once you have database, from the WooCommerce root directory run the following:
-
Install PHPUnit via Composer by running:
$ composer install
-
Install WordPress and the WP Unit Test lib using the
install.sh
script:$ tests/bin/install.sh <db-name> <db-user> <db-password> [db-host]
You may need to quote strings with backslashes to prevent them from being processed by the shell or other programs.
Example:
$ tests/bin/install.sh woocommerce_tests root root
# woocommerce_tests is the database name and root is both the MySQL user and its password.
Important: The <db-name>
database will be created if it doesn't exist and all data will be removed during testing.
Running Tests
Change to the plugin root directory and type:
$ vendor/bin/phpunit
The tests will execute and you'll be presented with a summary.
You can run specific tests by providing the path and filename to the test class:
$ vendor/bin/phpunit tests/legacy/unit-tests/importer/product.php
A text code coverage summary can be displayed using the --coverage-text
option:
$ vendor/bin/phpunit --coverage-text
Running tests in PHP 8
WooCommerce currently supports PHP versions from 7.0 up to 8.0, and this poses an issue with PHPUnit:
- The latest PHPUnit version that supports PHP 7.0 is 6.5.14
- The latest PHPUnit version that WordPress (and thus WooCommerce) supports is 7.5.20, but that version doesn't work on PHP 8
To workaround this, the testing strategy used by WooCommerce is as follows:
- We normally use PHPUnit 6.5.14
- For PHP 8 we use a custom fork of PHPUnit 7.5.20 with support for PHP 8. WooCommerce's GitHub Actions CI workflow is configured to use this fork instead of the old version 6 when running in PHP 8.
If you want to run the tests locally under PHP 8 you'll need to temporarily modify composer.json
to use the custom PHPUnit fork in the same way that the GitHub Actions CI workflow file does. These are the commands that you'll need (run them after a regular composer install
):
curl -L https://github.com/woocommerce/phpunit/archive/add-compatibility-with-php8-to-phpunit-7.zip -o /tmp/phpunit-7.5-fork.zip
unzip -d /tmp/phpunit-7.5-fork /tmp/phpunit-7.5-fork.zip
composer bin phpunit config --unset platform
composer bin phpunit config repositories.0 '{"type": "path", "url": "/tmp/phpunit-7.5-fork/phpunit-add-compatibility-with-php8-to-phpunit-7", "options": {"symlink": false}}'
composer bin phpunit require --dev -W phpunit/phpunit:@dev --ignore-platform-reqs
Just remember that you can't include the modified composer.json
in any commit!
Writing Tests
There are three different unit test directories:
tests/legacy/unit-tests
contains tests for code in theincludes
directory. No new tests should be added here, ever; existing test classes shouldn't get new tests either. Fixing faulty existing tests is allowed.tests/php/includes
is where all the new tests for code in theincludes
directory should be written.tests/php/src
is where all the tests for code in thesrc
directory should be written.
Each test file should correspond to an associated source file and be named accordingly:
* For src
code: The base namespace for tests is Automattic\WooCommerce\Tests
. A class named Automattic\WooCommerce\TheNamespace\TheClass
should have a test named Automattic\WooCommerce\Tests\TheNamespace\TheClassTest
.
* For includes
code:
* When testing classes: use the same approach as for src
except that namespaces are not used. So a WC_Something
class in includes/somefolder/class-wc-something.php
should have its tests in tests/src/internal/somefolder/class-wc-something-test.php
.
* When testing functions: use one test file per functions group file, for example wc-formatting-functions-test.php
for code in the wc-formatting-functions.php
file.
See also the guidelines for writing unit tests for src
code and the guidelines for includes
code.
General guidelines for all the unit tests:
- Each test method should cover a single method or function with one or more assertions
- A single method or function can have multiple associated test methods if it's a large or complex method
- Use the test coverage HTML report (under
tmp/coverage/index.html
) to examine which lines your tests are covering and aim for 100% coverage - For code that cannot be tested (e.g. they require a certain PHP version), you can exclude them from coverage using a comment:
// @codeCoverageIgnoreStart
and// @codeCoverageIgnoreEnd
. For example, seewc_round_tax_total()
- In addition to covering each line of a method/function, make sure to test common input and edge cases.
- Prefer
assertSame()
where possible as it tests both type and value - Remember that only methods prefixed with
test
will be run so use helper methods liberally to keep test methods small and reduce code duplication. If there is a common helper method used in multiple test files, consider adding it to theWC_Unit_Test_Case
class so it can be shared by all test cases - Filters persist between test cases so be sure to remove them in your test method or in the
tearDown()
method. - Use data providers where possible. Be sure that their name is like
data_provider_function_to_test
(i.e. the data provider fortest_is_postcode
would bedata_provider_test_is_postcode
). Read more about data providers here.
Automated Tests
Tests are automatically run with GitHub Actions for each commit and pull request.
Code Coverage
Code coverage is available on Codecov which receives updated data after each build.