History

Timon Davis af308da6b9 Fix bug #15103 where site operator cannot assign a variation with value of '0' as the default choice on the customer facing form. The WC_Product::set_default_attributes function uses an array_filter (using the default callback for filtration) to remove null and false values from the defaults array for a given product. The issue here is that, in the above use case, the array_filter will evaluate '0' as 0 and therefore as false. Ultimately, array_filter then prevents the value from being recorded, moving forward. I've added a new filter callback to includes/wc-attribute-functions which will disregard all FALSE PHP equivalents except for '0' (as a a string). Also, I've updated the filter_array call in WC_Product::set_default_attributes so that it uses this new callback, instead of the PHP default. Finally, I've added a phpunit test to assert that, when storing default variations / attributes on a product, the false/true PHP synonyms are evaluating and storing like one would normally expect, with the exception that (string) '0' evaluates as true in this special case. This solution could potentially be broadened to facililate similar rules elsewhere, but the need raised in the bug is specific and this is a specific solution.		2017-05-18 02:43:14 -07:00
..
bin	Stop download phpcs from GitHub and use the composer copy	2017-03-21 12:02:53 -03:00
cli	Merge percent and cart percent coupon types	2016-12-14 11:07:08 +00:00
e2e-tests	Remove readme.md in favor of wiki	2017-03-21 10:16:30 -07:00
framework	WC_Object_Query	2017-04-24 11:33:17 -07:00
unit-tests	Fix bug #15103 where site operator cannot assign a variation with value of '0' as the default choice on the customer facing form.	2017-05-18 02:43:14 -07:00
README.md	Updated tests readme.md example URL #12268	2016-11-07 18:00:00 -02:00
bootstrap.php	WC_Object_Query	2017-04-24 11:33:17 -07:00

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 the wc-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, see wc_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 the WC_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 for test_is_postcode would be data_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.