History

Ian Jenkins 2340f269cf Add support for custom attributes to wc_placeholder_img(). When displaying a list of images you often want a specific class to be attached to each image, therefore you pass through a custom class using the attr parameter. Unfortunately this doesn't get passed through to a placeholder image should one be needed. This means that, for example, if you're custom class center an image or something, it won't be honoured for placeholders, which can lead to some wonky image listings. You can work around this currently by leverging the `woocommerce_product_get_image` filter, but it's a bit gnarly as you need to do some regexing or string splitting or something and checking class names and what not. This provides a much easier way, by supporting custom attrs on placeholder images as is the case for non placehodler images.		2019-10-30 15:08:19 +00:00
..
bin	xvfb needs to be started in before_script	2019-08-05 14:43:54 +02:00
cli	Merge percent and cart percent coupon types	2016-12-14 11:07:08 +00:00
data	phpcs	2019-01-21 08:11:40 -08:00
e2e-tests	Update e2e test for variations to accomodate new missing price message on variations.	2019-07-14 17:47:30 +02:00
framework	Added unit test & updated other affected tests.	2019-10-02 14:59:42 +02:00
includes	Fixed SpeedTrapListener include	2019-07-18 22:24:40 -03:00
unit-tests	Add support for custom attributes to wc_placeholder_img().	2019-10-30 15:08:19 +00:00
README.md	Remove word "simply" from documentation	2019-08-23 10:46:22 -03:00
bootstrap.php	Fixed SpeedTrapListener include	2019-07-18 22:24:40 -03:00

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.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/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.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 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 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 Scrutinizer and Codecov which receives updated data after each Travis build.