Last Saturday I updated my virtual server from 16.04 LTS to 18.04.3 LTS. The upgrade took about an hour. It wasn’t too painful. I tried to use the maintainer’s configuration defaults wherever. Mostly it worked but I found a few problems I had to fix. The biggest problems I encountered from the upgrade were:
- My web pages were showing the PHP scripts rather than executing the script. Enabling PHP 7.2 in Apache2 solved that problem.
- In PHP 7.2 mcrypt is deprecated so it broke one of my applications. Since I did not set up my application to use encryption, the solution was to disable encryption in the application configuration.
- Every night I send myself a PERL report. The report complained about a missing module. So I installed the missing module into PERL using CPAN.
- A WordPress plugin complained about cURL was not installed. I installed php-curl using apt.
In my last post I thought I had set up PHPUnit correctly. As I worked through the samples I found out that there were a few more problems.
- The first problem was finding the Framework folder used in the samples. This folder exists under the test tree. To make things easy I copied the Framework, Extensions, Runner, and Util folders over to my working directory. As I said in previous post my working directory, phpunit, is located under the htdocs folder.
- The ObserverTest sample did not work for me as shown in the documentation. It complained about the Subject object. I got the Observer object to run but I think section of the documentation should be re-written. Mock objects are important.
- The second problem I found was when I was trying to run the BankAccountTest. It threw a BankAccountException and it expected to find the BankAccountException class somewhere. Sebastian has a slide online with an updated BankAccount.php that referenced a BankAccountException.php. I looked all around for the file but I could not find it. So I created my own file. It does nothing except create the BankAccountException class by extending Exception. Now the BankAccountTest sample will run.
- Getting the code coverage feature to work was a bit trickier. If you have not enabled xdebug you will get a confusing error message. When you run PHPUnit with the code coverage parameter, “–report”, it will say that there is no report parameter. Huh!? When you run “phpunit –help” you will not see the report parameter. Hmm… I thought I had fixed this.
- Go back and make sure that you have enabled the extension in the php.ini file. Oops, I had enabled the extensions in the wrong file.
- After enabling the xdebug extension I got an error message when I ran PHPUnit.bat that complained about the version of xdebug.dll and PHP. I am running the latest version of PHP and the xdebug.dll version it is loading looks like it is pretty old. After a couple of iterations I got the configuration correct. You need to enable the xdebug extension as a ZEND extension with the full path to the most recent version of the DLL. The most recent version exists in my ext folder but it had a different name. For my version of XAMPP I added the following line,
zend_extension_ts="C:\Program Files\xampp\php\ext\php_xdebug-2.0.0-5.2.2.dll". Now I get the pretty code coverage report.
So there you have it. I have gone through the examples and gotten all of them except one to work as expected.