Phpunit Woes

Update: it works if you install Laravel through composer (just confirmed) but not using the Laravel Installer. Weird man. Any one know why?

Maybe try and run composer update after installing with Laravel installer?

Yep, tried that...It said nothing to update or install

You've got the same problem with phpspec too, and just haven't discovered it yet. I tested it and got the same thing. With a bit of debugging I've found the problem...

Here's what's happening:

• If you run composer create-project laravel/laravel it does a proper "install", which sets permissions, uses proper symlinks, etc.
• If you run laravel new project, it basically just unzips a set of files, and does NOT set permissions, and does NOT symlink to the correct files.

vendor/bin/phpunit is supposed to be a symlink to vendor/phpunit/phpunit/phpunit which is the real executable. While in your case the files have the same content, the PHP logic inside which is trying to detect working directories is not expecting the actual executable to be in vendor/bin/phpunit. The PHP code in the file is written with the expectation that it's running from the symlink in vendor/phpunit/phpunit/phpunit.

I'm guessing the Laravel Installer should use a .tar package instead of a .zip, so it can retain symlinks and permissions.

For now I think the safer course of action is to stick with composer.

You could delete the vendor/phpunit folder and run composer update. Not the best solution but it should work instead of scraping the project and starting with a fresh install.

Same would work for phpspec.

Ya, I was just thinking the same thing.

Deleting the entire vendors folder works too, but that defeats the purpose of using laravel new

@ChrisB

Defeats the purpose unless you cannot remember the exact syntax for installing with composer. At this point I always use composer because it is muscle memory and using the Laravel installer just doesn't feel right to me.

Agreed.

Here's a tested workaround:

So, since in a new install there are supposed to be 4 symlinks in the vendor/bin folder, here's what you need to do:

1. Delete the following folders:

   • vendor/bin
   • vendor/classpreloader
   • vendor/phpspec
   • vendor/phpunit/phpunit (or just vendor/phpunit is fine too, but a bit overkill)
   • vendor/psy

2. Run composer update

That's fixed it fully for me, after using laravel new project.

Personally I'm only using composer. But @StormShadow now has a couple options.

Thanks @ChrisB and @akael, I really appreciate this!

Thanks @ChrisB

BTW, if you don't want your packages to be updated you may want to run composer install after removing vendor folders

@ChrisB Thanks for your great info. I just noticed some strange behavior tonight with homestead and php unit. I recently did a composer update (the only thing I changed is "minimum-stability": "stable" instead of "dev") then when i ssh into homestead and run vendor/bin/phpunit it immediately said "Killed" with no other output in the console. Before the composer update that command had worked fine. I think this has to do with the symlinking because when i run vendor/phpunit/phpunit/phpunit it works! Any insight or advice regarding what may be happening here?

Thanks @ChrisB !! Spent ages trying to work out why PHPSpec wasn't working... It was due to using

laravel new

I switched to installing with Composer and.. happy days :)

@StormShadow I think if your symlinks are broken again, it's best to look at the files in your vendor/bin folder and delete those files and the /vendor/xyz directories for those same files, then run composer install to rebuild the symlinks.

Agreed.

Here's a tested workaround:

So, since in a new install there are supposed to be 4 symlinks in the vendor/bin folder, here's what you need to do:

Delete the following folders:

vendor/bin vendor/classpreloader vendor/phpspec vendor/phpunit/phpunit (or just vendor/phpunit is fine too, but a bit overkill) vendor/psy Run composer update

That's fixed it fully for me, after using laravel new project.

Personally I'm only using composer. But @StormShadow now has a couple options.

This almost worked for me, had to run composer install after deleting the folders instead of composer update

may is the link file error. i just copy vendor/phpunit/phpunit/phpunit to project path then using ./phpunit is works!!!

@ChrisB thanks for your workaround. On Step 2 I had to run composer install, instead of composer update. composer update gave me this error:

PHP Warning:  require(/home/vagrant/Code/myproject/vendor/psy/psysh/src/Psy/functions          .php): failed to open stream: No such file or directory in /home/vagrant/Code/myproject/vendor/composer/autoload_real.php on line 54

But with composer install it works!

@chrisB @akael Very helpful posts guys.

Worked! But I had to:

composer update --no-scripts

May be necessary to run through php interpretor if on a VM:

php ./vendor/bin/phpunit

It's a broken symlink to phpunit when project files are installed with laravel installer and not composer. Easy to fix......

delete file "vendor/bin/phpunit"
delete folder "vendor\phpunit"
run composer install 

everything will be reinstalled/relinked and all will start working again.

UPDATE.... Its nothing to do with composer or broken symlinks. It's an error in the /vendor/bin/phpunit script executable. Well maybe not an 'error's such but it could do with being updated.

Phpunit needs to find the autoload.php file which is in the vendor folder for us in Laraveland. It searches for this file in 3 places but these 3 places are ALL relative to the /vendor/bin/ where the phpunit script executable resides and NOT where your PWD (present working directory) is. So.... the 3 places resolve to :-

__DIR__ . '/../../autoload.php' is equivalent to  '/autoload.php'
__DIR__ . '/../vendor/autoload.php'  is equivalent to '/vendor/vendor/autoload.php'
__DIR__ . '/vendor/autoload.php'  is equivalent to '/vendor/autoload/vendor/autoload.php'

which are all wrong as what we actually want is

'/vendor/autoload.php'

so update the /vendor/bin/phpunit script executable thus

foreach (array(__DIR__ . '/../autoload.php',__DIR__ . '/../../autoload.php', __DIR__ . '/../vendor/autoload.php', __DIR__ . '/vendor/autoload.php') as $file) 
{
    if (file_exists($file)) 
    {
        define('PHPUNIT_COMPOSER_INSTALL', $file);

        break;
    }
}

that is add

__DIR__ . '/../autoload.php',

to the array.

Seems to work fine now.

I had the same Issue when Laravel 5.3 was released and phpunit worked fine in 5.2 but not in 5.3 I have to update Laravel composer installer to 1.1.3 and then install Laravel framework using laravel new command and it work fine now..

I didn't install PHPUnit globally and didn't define the path. So for anyone who would have same problem :

composer global require phpunit/phpunit composer global require phpunit/dbunit Then you add this to you ~/.bash_profile or ~/.profile

export PATH=~/.composer/vendor/bin:$PATH