Sometimes PHPUnit silently fails like this [caption id=“attachment_234” align=“aligncenter” width=“1024”]
PHPUnit silent fail[/caption] Even if I can very well understand that something went wrong PHPUnit CLI is not giving me any hint.
Go verbose
Running PHPUnit via the CLI using the -v option makes PHPUnit print all of its possible outputs and, maybe, help in solving the silent death. Even better: I use PHPUnit configuration file, phpunit.xml, to avoid any lengthy console entry as PHPUnit states in the picture above.
Wrong includes and requires make PHPUnit go crazy
Many times PHPUnit fails due to some wrong includes or requires instructions: I always check those first thing for any kind of typos or mis-direction in paths.
Use a linter
A code linter is something that checks my code for any kind of syntax error. It usually comes embedded in any kind of software IDE and many IDEs also offer some dynamic linking to methods and functions defined in other files for the purpose of auto-completion and real-time check.
I do not use an IDE proper but chose Sublime Text instead and its plugin SublimeLinter to check my PHP code while working on it. [caption id=“attachment_235” align=“aligncenter” width=“829”]
Error spotted by linter[/caption] A linter will catch many PHPUnit-killer errors before they happen and will avoid some PHPUnit' non-ablative screen of death.
Read the log
All of my PHP development actually revolves around WordPress and using MAMP allows me to quickly access the error-log of the PHP version that comes with it
[caption id=“attachment_236” align=“aligncenter” width=“708”]
View error log in MAMP[/caption] The error log, the picture below is taken on a Mac machine, allows me to have a snapshot of what went wrong with PHP in the last run and try to fix it. [caption id=“attachment_237” align=“aligncenter” width=“1024”]
PHP error log on a Mac machine[/caption] If you run the version of PHP that comes embedded with your OS of choice then simply search for the php_error.log file (its default name) and read it.
Last in, first out
Nine times on ten the guilty code is the one you added last so commenting the last lines out and trying to run the tests again might help. Then un-comment the lines one by one and repeat. [caption id=“attachment_238” align=“aligncenter” width=“1024”]
Last added code commented[/caption]
Make my tests work THEN make my tests pass
I also try to dumb down my tests to the simplest form, sometimes empty, and use simpler versions of it. If I know a function will call some_method once with an argument and will require the mock to return some precise value I will write the lines below one by one incrementally adding code to my expectation and running the tests in between each increment
$this->mocks->filters->expects($this->once())->method('methodName');
$this->mocks->filters->expects($this->once())->method('methodName')->with($this->equalTo('some_argument'));
$this->mocks->filters->expects($this->once())->method('methodName')->with($this->equalTo('some_argument'))->will($this->returnValue('some_value'));
Adding incrementally allows me to know it’s the last addition that broke my code.