PHPunit test errors with `Parse error` on CI
Test code coverage GitLab can show you the code coverage in percent you have with your tests at various places: as a badge via a predefined URL in a merge request, also indicating if merging this code would increase or decrease code coverage and as a nice graph over time in the Analytics > Repository overview per project and on a group level Add a simple coverage report to : Enter fullscreen mode Exit fullscreen mode And tell GitLab-CI via the about this report (add the key): Enter fullscreen mode Exit fullscreen mode This assumes you are using Xdebug and have it already installed in the image your are using to run the tests in GitLab CI. I hope this small overview helps you get more out of GitLab and GitLab CI when working with PHP projects.
PHPunit test errors with `Parse error` on CI
I’m unit testing my code with the help of phpunit 9.3.8 . The tests run fine on my local dev environment (I’m running Windows 10, PHP 7.4.2 with Xdebug 2.9.2 ) but fail because of a parse error when I try to run phpunit on Gitlab CI (The CI runs the latest alpine linux image).
$ composer run test > phpunit PHPUnit 9.3.8 by Sebastian Bergmann and contributors. Runtime: PHP 7.3.23 with Xdebug 2.9.8 Configuration: /builds/gaspacchio/back-to-the-future/phpunit.xml Reporter ✘ Can set short message [6.05 ms] │ │ ParseError: syntax error, unexpected 'int' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) │ │ /builds/gaspacchio/back-to-the-future/src/api/utilities/Reporter.php:21 │ /builds/gaspacchio/back-to-the-future/src/api/tests/ReporterTest.php:12 │ // More errors Time: 00:01.970, Memory: 310.00 MB ERRORS! Tests: 6, Assertions: 0, Errors: 6. Generating code coverage report in Clover XML format . done [00:00.330] PHP Warning: fopen(/builds/gaspacchio/back-to-the-future/): failed to open stream: Is a directory in /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/src/Util/Printer.php on line 89 PHP Stack trace: PHP 1. () /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/phpunit:0 PHP 2. PHPUnit\TextUI\Command::main() /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/phpunit:61 PHP 3. PHPUnit\TextUI\Command->run() /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/src/TextUI/Command.php:100 PHP 4. PHPUnit\TextUI\TestRunner->run() /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/src/TextUI/Command.php:147 PHP 5. PHPUnit\Util\Printer->__construct() /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:756 PHP 6. fopen() /builds/gaspacchio/back-to-the-future/vendor/phpunit/phpunit/src/Util/Printer.php:89 Code Coverage Report: 2020-10-13 10:12:09 Summary: Classes: 0.00% (0/11) Methods: 0.00% (0/38) Paths: 0.00% (0/7) Branches: 0.00% (0/7) Lines: 0.00% (0/397) Script phpunit handling the test event returned with error code 2 Line 21 of the Reporter.php file is below:
And the line 12 of ReporterTest.php is:
I’m using the fixtures function of PHPunit, defined as :
PHPUnit supports sharing the setup code. Before a test method is run, a template method called setUp() is invoked. setUp() is where you create the objects against which you will test.
Type hinting of object properties is in PHP 7.4 and this is running
PHPUnit 9.3.8 by Sebastian Bergmann and contributors.
Runtime: PHP 7.3.23 with Xdebug 2.9.8
It’s basically a PHP version conflict, for some reason PHPUnit is trying to parse it like older PHP versions where private int $code; is invalid (and private $code; should be used instead).
Oh, just noticed your Windows system is running PHP 7.4 but Gitlab CI image has PHP 7.3.23 installed!
PHPUnit — Version 3.7.21 instead of Version 6 installed, Go to xampp/php/PEAR dir and delete two folders PHPUnit and PHPUnit2. Go to Control Panel, then navigate System and Security->System and click «Advanced system settings» link on the left. This will open Advanced tab in System Properties window. Click «Environment Variables» button, then under …
Can’t test the PHP package using PHPUnit, once I publish it
I’ve created a simple PHP library using PHP 5.6. It includes PHPUnit test cases and I succeeded in creating the package. Then I found that I can install these packages directly from GitHub, using composer, in other projects also. I can run tests independently at the development stage. But once I publish the package I can’t run the tests, as it is not properly finding the autoloader files.
I’ve added the XML files in root directory. The path of the autoload file is correct when it is independent. But the directory structure will be a different one once it is installed.
The problem still persist if we use require_once the autoloader file, as the directory structure change after installation.
- Can we test our package after installing it into any frameworks (laravel/Symfony) or in any other projects?
- What is the best practice? Is the test needed for the developers who is using the package?
- If yes, then any solution to solve this? Is there any other method to autoload problem in both environments?
I would say you’re best to look at the other repositories and see if it works or not.
cd vendor/phpunit/phpunit && composer install && phpunit => worked
cd doctrine/collections/ && composer install && phpunit => worked
So it seems that it should be working for you.
If you look at the phpunit.xml.dist for the other vendors they use:
bootstrap=»./tests/Doctrine/Tests/TestInit.php» (doctrine)
bootstrap=»tests/bootstrap.php» (phpunit)
It looks like your file isn’t so different. Are you sure you ran composer install from inside your packages directory inside the vendor folder?
Update:
I added your repository as a dependency to a default Symfony installation.
It ran fine. You need to run composer update and check in the new composer.lock because it’s out of date.
From there I cd’ed into the directory for your repo.
Update Two
(since this was too long for a comment)
@JTheDev composer update adds your dependencies for the laravel project, but it doesn’t create the vendor folder inside your vendor/your-project directory. If composer installed all dependencies separately for each project, like:
vendor/ my-project/ vendor/ dependency-A dependency-C another-library/ vendor/ dependency-A dependency-B it would waste a lot of space and bandwidth. Instead composer gets all the dependencies and installs them in separate folders and they work with each other because composer loads them all using vendor/autoload.php for that project . What you’re talking about is creating the vendor folder inside vendor/your-project . This is not normal — usually you only have to run tests when developing yourself, but anyway your question is about how to run your tests for your project when it’s added as a dependency for another project.
To do this you need to run composer install inside the vendor/your-project directory, that means:
cd vendor/Jthedev/Validators && composer install && vendor/phpunit/phpunit/phpunit
Final update (hopefully)
The autoloader is only generated when you run composer install inside your project directory. You are correct, the vendor folder should not be there usually but you need it if you want to do what you are trying to do. It is not conventional. Normally developers run their tests inside their project root folder, not on the dependencies, but your questions was «how can I run my tests when it is a dependency». The answer is you need to create the vendor and autoload files inside your project folder
The tests only run if you run composer install inside the project folder. But it’s not a problem if the tests don’t run without doing that.
Php — Installation failed for phpunit/phpunit ^6.2, If you run a composer update with the composer.lock file and the vendor folder present, Composer will take the installed versions into accounts before updating. Make sure you have the lock file committed into your project repository, to be able to restore the current version. Then try another update, but …
Revisiting GitLab as a PHP Developer
Every now and then it seems like a good idea to re-read the documentation of tools you’ve been using for years. In most cases you just update to the latest version and everything works fine, but you may not be using the latest features.
So here are some things I already knew, and some things I newly discovered when I re-read GitLab’s documentation after stumbling over this tweet:
Do you have experience with consuming cobertura xml generated by @phpunit in @gitlab #ci? Then please comment here: github.com/sebastianbergm… (or fix gitlab.com/gitlab-org/git…). Thanks!
TLDR
You may see all of the below in action in this demo merge request.
Unit test reports
The first thing I found is that GitLab has support for the JUnit XML file format and PHPUnit is able to write a JUnit XML file report. By configuring PHPUnit to create a JUnit XML and by declaring this an artefact in .gitlab-ci.yml you can have a nice unit test overview in the pipeline itself and the merge request.
Add the junit logging to your phpunit.xml file:
And tell GitLab-CI via the .gitlab-ci.yml about this report:
Unit Tests: stage: test script: - ./vendor/bin/phpunit artifacts: reports: junit: junit.xml What you get is a nice overview of the tests run, the time it took to run every single one in the pipeline and in the merge request overview page.
You may find more hints about this feature in the unit test reports section of the official GitLab docs.
Test code coverage
GitLab can show you the code coverage in percent you have with your tests at various places:
- as a badge via a predefined URL
- in a merge request, also indicating if merging this code would increase or decrease code coverage
- and as a nice graph over time in the Analytics >Repository overview per project and on a group level
Add a simple coverage report to phpunit.xml :
outputFile="php://stdout" showUncoveredFiles="false" showOnlySummary="true" /> And tell GitLab-CI via the .gitlab-ci.yml about this report (add the coverage key):
Unit Tests: stage: test script: - XDEBUG_MODE=coverage ./vendor/bin/phpunit coverage: '/^\s*Lines:\s*\d+.\d+\%./' This assumes you are using Xdebug and have it already installed in the image your are using to run the tests in GitLab CI. Find the documentation about this feature here.
Test code coverage visualization
This one was an absolut blast for me. While you are gathering code coverage to have a line coverage number you can see everywhere in GitLab, you can also create a line coverage report as Cobertura XML file format with PHPUnit that GitLab can read and show you covered and uncovered lines directly in the merge requests diff view.
Add a the cobertura coverage report to phpunit.xml :
And tell GitLab-CI via the .gitlab-ci.yml about this report (add the coverage_report artifacts key):
Unit Tests: stage: test script: - XDEBUG_MODE=coverage ./vendor/bin/phpunit artifacts: reports: coverage_report: coverage_format: cobertura path: cobertura.xml Read more about this awesome feature in the test coverage visualization documentation alongside some screenshots.
Code style violations
PHP CS Fixer is able to generate a GitLab formatted report which GitLab can use to show you any new violations in the code or even if Code style violations have been tackled.
Run PHP CS Fixer with the —format=gitlab argument and tell GitLab CI via the .gitlab-ci.yml where the report is to be found:
Coding guidelines: stage: static analysis script: - ./vendor/bin/php-cs-fixer fix -v --dry-run --format=gitlab --using-cache=no src/ > gl-cs-fixer.json || exit 0 artifacts: reports: codequality: gl-cs-fixer.json I hope this small overview helps you get more out of GitLab and GitLab CI when working with PHP projects.
The requested PHP extension dom is missing from your, — Installation request for phpunit/php-code-coverage (locked at 4.0.8) -> satisfiable by phpunit/php-code-coverage[4.0.8]. What I’ve tried Some other thread suggested that this is included in the php-xml package. I tried installing this