48480eb882
The WooCommerce unit tests started failing when running using WP nightly with the following error: ``` Fatal error: require_once(): Failed opening required '/tmp/wordpress-tests-lib/src//wp-includes/class-phpmailer.php' (include_path='.:/home/travis/.phpenv/versions/7.4.2/share/pear') in /tmp/wordpress-tests-lib/includes/mock-mailer.php on line 2 ``` https://travis-ci.org/woocommerce/woocommerce/jobs/646855363#L1955 This was happening because WP changed the syntax of the line where ABSPATH is defined in the context of the unit tests (https://core.trac.wordpress.org/changeset/47198/trunk/wp-tests-config-sample.php) and we rely on this syntax to change ABSPATH when running `tests/bin/install.sh`. To fix this problem, this commit updates the sed command used to change ABSPATH to work when both the old and new syntaxes are used. In the future we might want to consider a more robust solution to the problem of updating ABSPATH. |
||
|---|---|---|
| .. | ||
| bin | ||
| cli | ||
| data | ||
| e2e-tests | ||
| framework | ||
| includes | ||
| unit-tests | ||
| README.md | ||
| bootstrap.php | ||
README.md
WooCommerce Unit Tests
Initial Setup
From the WooCommerce root directory (if you are using VVV you might need to vagrant ssh first), run the following:
-
Install PHPUnit via Composer by running:
$ composer install -
Install WordPress and the WP Unit Test lib using the
install.shscript:$ 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/unit-tests/importer/product.php
A text code coverage summary can be displayed using the --coverage-text option:
$ vendor/bin/phpunit --coverage-text
Writing Tests
- Each test file should roughly correspond to an associated source file, e.g. the
formatting/functions.phptest file covers code in thewc-formatting-functions.phpfile - 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:
// @codeCoverageIgnoreStartand// @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
testwill 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_Caseclass 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_postcodewould bedata_provider_test_is_postcode). Read more about data providers here.
Automated Tests
Tests are automatically run with Travis-CI for each commit and pull request.
Code Coverage
Code coverage is available on Scrutinizer and Codecov which receives updated data after each Travis build.