I seem to remember three years ago or so - the last time I looked into PHP - that it was simple to run PHP Unit tests.
However now I am looking around and I cant find any simple solution. Everything I try has too many requirements, either:
It requires shell access to the php server (to run from the command line)
Or I can use Visual PHP Unit but then I have a whole set of other requirements ...
see:
It requires Apache. (for .htaccess)
It requires OVERRIDE ALL
It requires PEAR
It requires a database
Is there a simpler way to run PHP Unit tests? Something that would just require PHP scripts and a browser? or at the most composer?
Something that would work in the average limited bare bones low budget hosting environment?
Related
Currently we have written some unit test for our php laravel 5.5 application using codeception. just for additional info, our laravel code base have around 200k LOC. For normal unit test run, we noticed that it is really fast in which we can get more than 200 tests to finish within 1 hour.
But the main issue is that when we enabled codecoverage in codeception which is using xdebug by default, we noticed the execution time increased drastically.
Now it already took 1 week but the whole codecoverage execution not even finished yet.
I am not sure whether this is the problem from codeception or xdebug itself but if anybody have experiences running php codecoverage on a huge codebase, it would be nice if you can share how you achieve it. Would appreciate it also if somebody can suggest any other tools to look into. Currently we are considering switching to phpunit but are still open to other tools to explore.
Replacing Codeception with PHPUnit will be a lot of work for little gain, because Codeception uses PHPUnit and its PHP-Code-Coverage library under the hood.
There is a new code coverage extension, called pcov which is supposedly much faster than xdebug.
https://github.com/krakjoe/pcov/blob/develop/INSTALL.md
I haven't tried to use it, but be aware that it requires PHPUnit 8, which is only available on PHP 7.2 or later versions.
Recently I have seen code coverage sped up by replacing xdebug with phpdbg - I can't give exact numbers as the code base has extensive functional tests in its test run (and the speed-up was only for unit tests), but a 2+ hour test and coverage run has been reduced to around 50 minutes.
Note that xdebug and phpdbg can differ in their code coverage (it looked like xdebug better dealt with opcache optimisations).
edit:
Since replacing xdebug with phpdbg, I have seen further speed improvements by replacing phpdbg with pcov.
I want to allow my testers to use the development website "as usual" and collect code coverages of every "run", combined everything and be able to say "after 4 hours of tests, here are the 75% of the code that were executed".
I use the php-code-coverage library (https://github.com/sebastianbergmann/php-code-coverage) and everything is working fine except that with xdebug as the tool used for code coverage it's way too slow (10 times slower that without activating php-code-coverage).
I've compiled my own version of php 7.2 with "--enable-phpdbg" and with the help of the command "update-alternatives" I'm able to run in cli :
$ php index.php
and get the code coverage I need, and it's only two times slower (every call to "php" is calling "phpdbg").
But I can't find a way to make it work with apache so that when I'm loading my website it's the executable "phpdbg" and not "php" that is used.
Even if I'm compiling my own ".so" it will still be "php" that will be executed.
I have a task of running tests to a Drupal 8 website.
I have a linux box.
I have successfully configured Behat + Mink.
My tests runs OK when I'm using the default goutte in behat.yml. But when I add #javascript so it runs with selenium2, it takes too long to run (up to 25 minutes for a login test).
So I read the docs to see if I did something wrong but can't understand how it works.
I have installed Selenium for Python3 and I can do a very simple get and assert of a webpage, and it is supposed to use Firefox in headless mode, it runs somewhat fast (less than one minute), so I don't know what could be wrong in my PHP setup, using composer.
The question is, do I need the Selenium Server all tutorials talk about? (those tutorials are aged). In the Selenium docs it says that Selenium Server is optional and I only need this if doing Non-remote. What would be this? Does Non-remote means that it is not meant to be run in a specialized server? I only need to run my tests in the machine hosting the app.
Also, why could it be taking so much to run a simple test? What logs can I look at?
You need selenium server + driver for specific browser for when you are running on local pc.
You need a selenium server running, so you need to start one(local/non-remote) or point to a machine that has selenium server(remote) for example when using services la BrowserStack or SauceLabs.
#javascript is so that he knows to start a driver with JS enabled.
If it take so much time to run a login test then you are doing something wrong, maybe you have some fixed waits or other conditions that are never true and they run until timeout.
Run Behat with -vvv flag, this is to increase the details of the logs.
Debug step by step and see where the issues is, try on your local pc first.
You should check for Behat tutorials, different frameworks are handling things differently, some you need only the driver, some both driver and the selenium server and some none of them because they have scripts to download and start the server automatically.
Also check for some best practices if you are new to automation.
Other related question is this one.
For starting selenium check this.
I've successfully deployed the Laravel application to Heroku.
It works online.
But when I try to run "heroku local" I get:
vendor/bin/heroku-php-apache2: No such file or directory
Which makes sense, since looking into "vendor/bin", the only thing listed is:
psysh -> ../psy/psysh/bin/psysh
So, where's my heroku-php-apache or how do I fix this?
You should have these lines in your composer.json
"require-dev": {
"heroku/heroku-buildpack-php": "*"
}
be sure to run composer update after you add them.
After extensive research, trial and error and talking to the Heroku Support team, I found out that, although Slow Loris's answer was a part of the process, the following answer was given to me by Heroku's Support:
To cut a long story short, heroku local is not officially supported for PHP >applications. The reason is that unlike all the other languages we support on the >platform, PHP has no web servers written in userland. Instead, we use PHP-FPM >together with Apache or Nginx, and the boot scripts (vendor/bin/heroku-(php|hhvm)-(apache2|nginx)) dynamically inject the correct configuration for port >binding and the FastCGI comms sockets.
This works with vanilla PHP and Apache builds, provided that:
1) the current user has all the correct permissions (in your case, >/var/log/apache2/ isn't writable);
2) the correct proxy modules are loaded in the main httpd.conf;
3) the main httpd.conf doesn't bind to a port at all, or at least not to one >under 1024 (which are reserved for superusers).
The main config also needs to be handled by each user on their own, because >sometimes, the modules to be loaded are in libexec/, sometimes in >lib/apache2/modules/, and so forth. Just too many variations; otherwise, we could >ship a full Apache config to users and the experience would be much better.
But the problems don't end there. FPM does not work at all on Windows, and on >most Linux systems, httpd is not a command that works; instead, apache2ctl >handles starting and stopping, and thus, running a server in the foreground is >not possible. In the end, there are simply too many possible permutations in >system configs that make it impossible to ensure every user has a great >experience.
It's simply the current reality in PHP land. Ruby, Python, Node, Java all have >web servers that are written in each respective language, and you don't need >external servers. Which also makes it possible to stream file uploads, handle web >socket upgrades, and so forth. Maybe with PHP 7 we'll see something like that >emerge soon (in PHP 5 it's simply not feasible at all, because a fatal error >kills the engine, so your web server would be gone too).
I know this question is a little dated but I recently deployed a heroku app for the first time and was unable to get heroku local to work for me. I'm on the current branch of Laravel which is 5.8, I am also on Windows 10 using VS Code. I searched all over trying to rectify this issue and could not get it to work no matter what.
I did come up with a solution to be able to work on this locally with only a few lines in terminal.
In VS Code, I used gitbash terminal, once in my heroku project folder composer require laravel/homestead --dev, once that is complete, then we need to install homestead, vendor/bin/homestead make, and then once that is complete, simply run vagrant up and your app will be accessible through localhost:8000.
Docs - https://laravel.com/docs/5.8/homestead
Hope this helps someone!
I'm used to using python's virtualenv tool to create separate environments that can mimic deployment environments for projects I write.
Now, I'm going to be working on a php project and I'm wondering if there's any equivalent to that? Specifically I'm hoping to be able to run one virtualhost on apache with one (older) version of php, while everything else runs on the normal up to date version.
My development machine is running ubuntu 11.04, so solutions that work on that platform would be preferred.
Assuming that you are using mod_php, there is no way to load multiple different versions into the same Apache instance. You can run multiple different versions if you're running PHP as CGI or FastCGI, but this will itself introduce some differences in behavior from mod_php.
Another alternative to virtual machines is docker.
As loading different versions of php within apache with mod_php seems not to be posible, the easiest way of mimicking deployment and development setups will be with a virtualmachine, which you stated you would like to avoid.
One way of making the burden of vm's for developers a bit easier is to use something like vagrant. With two files (the vagrant file, and the chef/puppet file) you can "version" your vm's, easily create them and destroy them for each project and when needed.
virtPHP is a tool for creating and managing multiple isolated PHP environments on a single machine. It's like Python's virtualenv, but for PHP. (README)
https://github.com/virtphp/virtphp
You might be interested in this: https://github.com/phpenv/phpenv
(Haven't coded php in years, so this might be outdated)
As far as I remember you just had to point to another directory where your libraries reside (include PATH), using something like:
include_path = .:/usr/local/lib/php:./include (this goes in php.ini, default libararies)
and in your php files:
ini_set("include_path", ".:../:./include:../include");
PHP never really had a robust packaging system and library repository like perl/python/ruby has, PEAR was trying to move in that direction but it is very closed in comparison and was hard to configure in multiproject environments.
Phark is trying to build a brew/bundler port for php, https://github.com/lox/phark, although it's not deployment ready.
As of now, there is no out of the box solution to this problem. The only solution which comes close is Vagrant and puPHPet.com as discussed here: https://drupal.org/node/2055947
Why can't we have an environment like python's virtualenv or ruby's rbenv? It makes up a nice open source project. Multiple instances of PHP can be handy if we want to test out some libraries in sandboxes rather than globally. We can install dependencies for different projects using a package manager like Composer.
Cloudlinux with PHP Selector has this for ages. It is integrated with popular control panels like CPanel, DirectAdmin etc.
Each linux account can have its own version of php and select any extensions they sit fit.
https://www.cloudlinux.com/php-selector