|
| 1 | +--- |
| 2 | +layout: doc |
| 3 | +title: Codeception - Documentation |
| 4 | +--- |
| 5 | + |
| 6 | +## Code Coverage |
| 7 | + |
| 8 | +At some point you want to review which parts of your appliaction are tested well and which are not. |
| 9 | +Just for this case the [CodeCoverage](http://en.wikipedia.org/wiki/Code_coverage) is used. When you execute your tests to collect coverage report, |
| 10 | +you will receive statisitcs of all classes, methods, and lines triggered by these tests. |
| 11 | +The ratio between all lines in script and all touched lines is a main coverage criteria. In the ideal world you should get a 100% code coverage, |
| 12 | +but in reality 80% are just enough. And even 100% code coverage rate doesn't save you from fatal errors and crashes. |
| 13 | + |
| 14 | +**Codeception has CodeCoverage tools since 1.5. To collect coverage information `xdebug` is required**. |
| 15 | + |
| 16 | + |
| 17 | + |
| 18 | +Coverage data can be collected manually for local tests and remote tests. Remote tests may be executed on different node, |
| 19 | +or locally, but behind the web server. It may look hard to collect code coverage for Selenium tests or PhpBrowser tests. But Codeception |
| 20 | +supports remote codecoverage as well as local. |
| 21 | + |
| 22 | +### Configuration |
| 23 | + |
| 24 | +To enable codecoverge put these lines to the global configuration file `codeception.yml`: |
| 25 | + |
| 26 | +{% highlight yaml %} |
| 27 | + yml |
| 28 | +coverage: |
| 29 | + enabled: true |
| 30 | + |
| 31 | +{% endhighlight %} |
| 32 | + |
| 33 | +that's ok for now. But what files should be present in final coverage report? You can filter files by providing blacklist and whitelist filters. |
| 34 | + |
| 35 | +{% highlight yaml %} |
| 36 | + yml |
| 37 | +coverage: |
| 38 | + enabled: true |
| 39 | + whitelist: |
| 40 | + include: |
| 41 | + - app/* |
| 42 | + exclude: |
| 43 | + - app/cache/* |
| 44 | + blacklist: |
| 45 | + include: |
| 46 | + - app/controllers/* |
| 47 | + exclude: |
| 48 | + - app/cache/CacheProvider.php |
| 49 | + |
| 50 | + |
| 51 | +{% endhighlight %} |
| 52 | +What are whitelists and blacklists? |
| 53 | + |
| 54 | +* A **whitelist** is a list of files that should be included in report even they were not touched. |
| 55 | +* A **blacklist** is a list of files that should be excluded from report even they were touched. |
| 56 | + |
| 57 | +Pass an array of files or directory to include/exclude sections. The path ending with '*' matches the directory. |
| 58 | +Also you can use '*' mask in a file name, i.e. `app/models/*Model.php` to match all models. |
| 59 | + |
| 60 | +There is a shortcut if you don't need that complex filters: |
| 61 | + |
| 62 | +{% highlight yaml %} |
| 63 | + |
| 64 | +coverage: |
| 65 | + enabled: true |
| 66 | + include: |
| 67 | + - app/* |
| 68 | + exclude: |
| 69 | + - app/cache/* |
| 70 | + |
| 71 | +{% endhighlight %} |
| 72 | + |
| 73 | +These `include` and `exclude` options are to add or remove files from a whitelist. |
| 74 | + |
| 75 | +All these settings can be redefined for each suite in their config files. |
| 76 | + |
| 77 | +## Local CodeCoverage |
| 78 | + |
| 79 | +The basic codecoverage can be collected for functional and unit tests. |
| 80 | +If you performed configurations steps from above you are ready to go. |
| 81 | +All you need is to execute codeception with `--coverage` option. |
| 82 | +To generate a clover xml report or a tasty html report append also `--xml` and `--html` options. |
| 83 | + |
| 84 | +{% highlight yaml %} |
| 85 | + |
| 86 | +codecept run --coverage --xml --html |
| 87 | + |
| 88 | +{% endhighlight %} |
| 89 | + |
| 90 | +XML and HTML reports are stored to the `_logs` directory. The best way to review report is to open `index.html` from `tests/_logs/coverage` in your browser. |
| 91 | +XML clover reports are used by IDEs (like PHPStorm) or Conitinious Integration servers (Like Jenkins). |
| 92 | + |
| 93 | +## Remote CodeCoverage |
| 94 | + |
| 95 | +If you run your application via Webserver (Apache, Nginx, PHP WebServer) you don't have a direct access to tested code, |
| 96 | +so collecting coverage becomes a non-trivial task. The same goes to scripts that are tested on different node. |
| 97 | +To get access to this code you need `xdebug` installed with `remote_enable` option turned on. |
| 98 | +Codeception also requires a little spy to interact with your application. As your application run standalone, |
| 99 | +without even knowing it is being tested, a small file should be included in order to collecto coverage info. |
| 100 | + |
| 101 | +This file is called `c3.php` and is [available on GitHub](https://github.com/Codeception/c3). |
| 102 | +`c3.php` should be downloaded and included in your application in a very first line of it's from controller. |
| 103 | +By sending special headers Codeception will command your appliaction when to start codecoverage collection and when to stop it. |
| 104 | +After the suite is finished, a report will be stored and Codeception will grab it from your application. |
| 105 | + |
| 106 | +Please, follow installation instructions described in a [readme file](https://github.com/Codeception/c3). |
| 107 | + |
| 108 | +After the `c3.php` file is included in application you can start gather coverage. |
| 109 | +In case you execute your application locally there is nothing to be changed in config. |
| 110 | +All codecoverage reports will be collected as usual and marged afterwards. |
| 111 | +Think of it: Codeception runs remote coverage in the same way as local. |
| 112 | + |
| 113 | +It's never been easier to setup remote codecoverage for your application. In ay other framework. Really. |
| 114 | + |
| 115 | +But if you run tests on different server (or your webserver doesn't use code from current directory) a single option `remote` should be added to config. |
| 116 | +For example, let's turn on remote coverage for acceptance suite in `acceptance.suite.yml` |
| 117 | + |
| 118 | +{% highlight yaml %} |
| 119 | + |
| 120 | +coverage: |
| 121 | + enabled: true |
| 122 | + remote: true |
| 123 | + |
| 124 | +{% endhighlight %} |
| 125 | + |
| 126 | +In this case remote Code Coverage results won't be merged with local ones if this option is enabled. |
| 127 | +Merging is possible only in case a remote and local file have th same path. |
| 128 | +But in case of running tests on a remote server we are not sure of it. |
| 129 | + |
| 130 | +## Conclusion |
| 131 | + |
| 132 | +It's never been easier to setup local and remote code coverage. Just one config and one additional file to incldue! |
| 133 | +**With Codeception you can easily generate CodeCoverage reports for your Selenium tests** (or other acceptance or api tests). Mixing reports for `acceptance`, `functional`, and `unit` suites provides |
| 134 | +you the most complete information on which parts of your applications are tested and which are not. |
| 135 | + |
| 136 | + |
0 commit comments