38f379a7d7
Right now get_item() is loading an item from the database directly. It doesn't take advantage of our cache and it doesn't check if the item is already loaded in memory. There is also another bug (or feature?) that it will let you load any item, even if the item is not related to the current order. I believe this is a bug, if somebody really wants to load any item regardless of the order they should use `WC_Order_Factory::get_order_item`. Another bug is that items loaded with get_item() are not related to the order object, therefore any calls to Order::save() won't persist the changes made to the item. This commits makes sure the item returned by get_item is loaded similarly like get_items() does, taking advantage of the cache and the $items protected property (chances are the item is already in memory, ready to be used). If a given item is not found false will be returned. If item exists but it is not related to the current object it will return false as well (If this behaviour is wanted, I can easily change it load the item anyways instead of returning false). |
||
---|---|---|
.. | ||
bin | ||
cli | ||
e2e-tests | ||
framework | ||
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-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/webhooks
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 Coveralls which receives updated data after each Travis build.