Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Code Coverage2:52 with Alena Holligan
As we start testing our code, it would be helpful to know which code is tested and which is not. Code coverage can give us a starting point for seeing which section of the code still requires testing.
<filter> <whitelist processUncoveredFilesFromWhitelist="true"> <directory suffix=".php">classes</directory> </whitelist> </filter> <logging> <log type="coverage-html" target="tests/log/report" lowUpperBound="35" highLowerBound="70"/> <log type="coverage-text" target="php://stdout" showUncoveredFiles="false"/> <log type="testdox-html" target="tests/log/testdox.html"/> <log type="testdox-text" target="tests/log/testdox.txt"/> </logging>
Xdebug is an extension for PHP to assist with debugging and development. It contains a single step debugger to use with IDEs; it upgrades PHP's var_dump() function; it adds stack traces for Notices, Warnings, Errors and Exceptions; it features functionality for recording every function call and variable assignment to disk; it contains a profiler; and it provides code coverage functionality for use with PHPUnit.
Enable Xdebug in MAMP for Mac
After installing Xdebug, follow the steps below to enable Xdebug in MAMP, non-pro version. MAMP Pro allows for a simple check box in preferences under PHP.
Step 1: Determine PHP Version
In MAMP, press Open start page View phpinfo to get PHP version Note which PHP version you have
Step 2: Configure php.ini
MAMP has two configuration files for each PHP version:
- Locate the xdebug section at the bottom of both of these files
- Uncomment zend_extension line in both files (remove the ;)
- Add the following lines to the xdebug section in both files:
xdebug.remote_enable=1 xdebug.remote_host=127.0.0.1 xdebug.remote_connect_back=1 # Not safe for production servers xdebug.remote_port=9000 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_autostart=true
Result should look something like:
[xdebug] zend_extension="/Applications/MAMP/bin/php/php7.0.8/lib/php/extensions/no-debug-non-zts-20151012/xdebug.so" xdebug.remote_enable=1 xdebug.remote_host=127.0.0.1 xdebug.remote_connect_back=1 # Not safe for production servers xdebug.remote_port=9000 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_autostart=true
Step 3: Restart MAMP!
Restart MAMP and Xdebug should be all set for whatever environment you use!
Visit the page you desire to debug with ?XDEBUG_SESSION_START=xdebug appended to the URL.
For code coverage to work, you'll need to have Xdebug installed. 0:00 Xdebug is a PHP extension, so you do not install it through Composer. 0:05 For details on installation, check the notes associated with this video. 0:10 Once Xdebug is installed, we can add code coverage to our phpunit.xml file. 0:15 We'll need to add whitelisting to tell PHPUnit which files to check. 0:23 Let's copy these lines. 0:31 In our phpunit.xml file, we'll add the filter 0:34 We're only going to need the directory. 0:44 We want to use our class's directory. 0:49 And we want to test all files ending in .php. 0:53 Next we want to set up logging. 0:58 Let's copy these lines. 1:03 And after our filter, 1:06 We're going to use our coverage-html. 1:12 And we're going to use our coverage-text so that we can output to the terminal. 1:16 We'll also keep our lines for the testdox-html and testdox-text. 1:23 Let's change our path. 1:28 We'll set this to tests/logs, As well as here, 1:32 test/logs, tests/logs. 1:40 Now let's try running our test again. 1:49 When we run our test, we see a simple Code Coverage Report. 1:57 That combines all the files from our classes directory. 2:01 We then see additional details for the classes that actually have some tests. 2:05 We also have a new directory named logs within our tests. 2:10 We have the testdox that we looked at before. 2:15 But now we also have a reports folder. 2:17 This folder contains some HTML files that we can view in the browser. 2:20 We see this nicely formatted report. 2:24 And we can scroll into our tests. 2:27 We can see the construct and the getTitle methods are actually tested. 2:29 100% code coverage still may not cover all scenarios. 2:34 Just because all lines are covered by a test, 2:39 does not mean that they're tested against all input. 2:43 But the more tests you have, 2:46 the more confident you can be that your code is working. 2:48
You need to sign up for Treehouse in order to download course files.Sign up