1860cd1933
This commits changes WC_Unit_Test_Case parent class to WP_HTTP_TestCase (which extends WP_UnitTestCase). This way all WC core test classes can benefit from the functionality provided by WP_HTTP_TestCase if needed. This is necessary because otherwise test classes can use the functionality provided by WC_Unit_Test_Case or WP_HTTP_TestCase. This change should not affect test classes that don't explicitly call one of the WP_HTTP_TestCase features. |
||
---|---|---|
.. | ||
bin | ||
cli | ||
e2e-tests | ||
framework | ||
includes | ||
unit-tests | ||
README.md | ||
bootstrap.php |
README.md
WooCommerce Unit Tests
Initial Setup
-
Install PHPUnit by following their installation guide. If you've installed it correctly, this should display the version:
$ phpunit --version
-
Install WordPress and the WP Unit Test lib using the
install.sh
script. Change to the plugin root directory and type:$ tests/bin/install.sh <db-name> <db-user> <db-password> [db-host]
Sample usage:
$ tests/bin/install.sh woocommerce_tests root root
Important: The <db-name>
database will be created if it doesn't exist and all data will be removed during testing.
Running Tests
Simply change to the plugin root directory and type:
$ phpunit
The tests will execute and you'll be presented with a summary. Code coverage documentation is automatically generated as HTML in the tmp/coverage
directory.
You can run specific tests by providing the path and filename to the test class:
$ phpunit tests/unit-tests/api/orders
A text code coverage summary can be displayed using the --coverage-text
option:
$ phpunit --coverage-text
Writing Tests
- Each test file should roughly correspond to an associated source file, e.g. the
formatting/functions.php
test file covers code in thewc-formatting-functions.php
file - 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
assertsEquals()
where possible as it tests both type & equality - 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 Travis-CI for each commit and pull request.
Code Coverage
Code coverage is available on Scrutinizer and Code Climate which receives updated data after each Travis build.