woocommerce/tests
Brent Sessions c64a35300a Take screenshots of failed e2e tests (#20313)
This adds screenshots for broken e2e tests. The screenshots will also be uploaded to an Amazon S3 instance from Travis CI so they can be viewed. If run locally, there will be a screenshots directory created where they can be viewed

If there is a failed e2e test you'll see a block under `travis.sh after` in the build log in Travis CI that will give the URLs for the images.

* Adding screenshot capabilities to all tests

* trying screenshots on S3

* try to get a failed test

* finding the right path

* fixing yml

* only taking failed screenshots

* fixing yml

* moving paths to env

* fixing target

* try without artifact target

* fixing test

* setting back temporary changes

* fixing spacing

* unneeded change

* trying different uploader

* Force a failed test

* fixing test again

* fixing  unneeded change

* updating git ignore
2018-06-07 11:31:37 -03:00
..
bin Take screenshots of failed e2e tests (#20313) 2018-06-07 11:31:37 -03:00
cli Merge percent and cart percent coupon types 2016-12-14 11:07:08 +00:00
e2e-tests Take screenshots of failed e2e tests (#20313) 2018-06-07 11:31:37 -03:00
framework Improve can_refund_order and add unit tests 2018-04-03 17:09:09 +01:00
includes Use WordPress version of phpunit-speed-trap 2018-05-17 15:04:32 +01:00
unit-tests Merge branch 'master' 2018-06-07 11:24:12 +01:00
README.md Merge branch 'master' into feature/webhook-crud 2017-11-07 12:42:28 -02:00
bootstrap.php Improve can_refund_order and add unit tests 2018-04-03 17:09:09 +01:00

README.md

WooCommerce Unit Tests

Initial Setup

  1. Install PHPUnit by following their installation guide. If you've installed it correctly, this should display the version:

    $ phpunit --version
    
  2. 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 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 Scrutinizer and Code Climate which receives updated data after each Travis build.