|
| 1 | +# Running Module Tests |
| 2 | + |
| 3 | +This is the quick-start to CodeIgniter testing. Its intent is to describe what |
| 4 | +it takes to set up your module and get it ready to run unit tests. |
| 5 | +It is not intended to be a full description of the test features that you can |
| 6 | +use to test your module. Those details can be found in the documentation. |
| 7 | + |
| 8 | +## Resources |
| 9 | +* [CodeIgniter 4 User Guide on Testing](https://codeigniter4.github.io/userguide/testing/index.html) |
| 10 | +* [PHPUnit docs](https://phpunit.readthedocs.io/en/8.3/index.html) |
| 11 | + |
| 12 | +## Requirements |
| 13 | + |
| 14 | +It is recommended to use the latest version of PHPUnit. At the time of this |
| 15 | +writing we are running version 7.5.1. Support for this has been built into the |
| 16 | +**composer.json** file that ships with CodeIgniter and can easily be installed |
| 17 | +via [Composer](https://getcomposer.org/) if you don't already have it installed globally. |
| 18 | + |
| 19 | + > composer install |
| 20 | + |
| 21 | +If running under OS X or Linux, you can create a symbolic link to make running tests a touch nicer. |
| 22 | + |
| 23 | + > ln -s ./vendor/bin/phpunit ./phpunit |
| 24 | + |
| 25 | +You also need to install [XDebug](https://xdebug.org/index.php) in order |
| 26 | +for code coverage to be calculated successfully. |
| 27 | + |
| 28 | +## Setting Up |
| 29 | + |
| 30 | +A number of the tests use a running database. |
| 31 | +In order to set up the database edit the details for the `tests` group in |
| 32 | +**phpunit.xml**. Make sure that you provide a database engine that is currently running |
| 33 | +on your machine. More details on a test database setup are in the |
| 34 | +*Docs>>Testing>>Testing Your Database* section of the documentation. |
| 35 | + |
| 36 | +## Running the tests |
| 37 | + |
| 38 | +The entire test suite can be run by simply typing one command-line command from the main directory. |
| 39 | + |
| 40 | + > ./phpunit |
| 41 | + |
| 42 | +You can limit tests to those within a single test directory by specifying the |
| 43 | +directory name after phpunit. |
| 44 | + |
| 45 | + > ./phpunit app/Models |
| 46 | + |
| 47 | +## Generating Code Coverage |
| 48 | + |
| 49 | +To generate coverage information, including HTML reports you can view in your browser, |
| 50 | +you can use the following command: |
| 51 | + |
| 52 | + > ./phpunit --colors --coverage-text=tests/coverage.txt --coverage-html=tests/coverage/ -d memory_limit=1024m |
| 53 | + |
| 54 | +This runs all of the tests again collecting information about how many lines, |
| 55 | +functions, and files are tested. It also reports the percentage of the code that is covered by tests. |
| 56 | +It is collected in two formats: a simple text file that provides an overview as well |
| 57 | +as a comprehensive collection of HTML files that show the status of every line of code in the project. |
| 58 | + |
| 59 | +The text file can be found at **tests/coverage.txt**. |
| 60 | +The HTML files can be viewed by opening **tests/coverage/index.html** in your favorite browser. |
| 61 | + |
| 62 | +## PHPUnit XML Configuration |
| 63 | + |
| 64 | +The repository has a ``phpunit.xml.dist`` file in the project root that's used for |
| 65 | +PHPUnit configuration. This is used to provide a default configuration if you |
| 66 | +do not have your own configuration file in the project root. |
| 67 | + |
| 68 | +The normal practice would be to copy ``phpunit.xml.dist`` to ``phpunit.xml`` |
| 69 | +(which is git ignored), and to tailor it as you see fit. |
| 70 | +For instance, you might wish to exclude database tests, or automatically generate |
| 71 | +HTML code coverage reports. |
| 72 | + |
| 73 | +## Test Cases |
| 74 | + |
| 75 | +Every test needs a *test case*, or class that your tests extend. CodeIgniter 4 |
| 76 | +provides a few that you may use directly: |
| 77 | +* `CodeIgniter\Test\CIUnitTestCase` - for basic tests with no other service needs |
| 78 | +* `CodeIgniter\Test\CIDatabaseTestCase` - for tests that need database access |
| 79 | + |
| 80 | +Most of the time you will want to write your own test cases to hold functions and services |
| 81 | +common to your test suites. |
| 82 | + |
| 83 | +## Creating Tests |
| 84 | + |
| 85 | +All tests go in the **tests/** directory. Each test file is a class that extends a |
| 86 | +**Test Case** (see above) and contains methods for the individual tests. These method |
| 87 | +names must start with the word "test" and should have descriptive names for precisely what |
| 88 | +they are testing: |
| 89 | +`testUserCanModifyFile()` `testOutputColorMatchesInput()` `testIsLoggedInFailsWithInvalidUser()` |
| 90 | + |
| 91 | +Writing tests is an art, and there are many resources available to help learn how. |
| 92 | +Review the links above and always pay attention to your code coverage. |
| 93 | + |
| 94 | +### Database Tests |
| 95 | + |
| 96 | +Tests can include migrating, seeding, and testing against a mock or live<sup>1</sup> database. |
| 97 | +Be sure to modify the test case (or create your own) to point to your seed and migrations |
| 98 | +and include any additional steps to be run before tests in the `setUp()` method. |
| 99 | + |
| 100 | +<sup>1</sup> Note: If you are using database tests that require a live database connection |
| 101 | +you will need to rename **phpunit.xml.dist** to **phpunit.xml**, uncomment the database |
| 102 | +configuration lines and add your connection details. Prevent **phpunit.xml** from being |
| 103 | +tracked in your repo by adding it to **.gitignore**. |
0 commit comments