Laravel version: master
I just fork this repo and run composer test on master branch. I got a fail test for my PHPUnit. I already run composer install. Is there anything that I'm doing wrongly?

I'm using windows 10. PHP 7.4.5
Please share the text of the 1st error message with us.
1) Tests\FeaturesTest::testFeatures with data set "Methods\Builder.php" ('E:\Code\Package\larastan\test...er.php')
null
@szepeviktor this one?
馃槻 Just a lonely null??
Try with --debug or with -v!
vendor/bin/phpunit --debug --stop-on-defect
yup, same.
There were 47 failures:
1) Tests\FeaturesTest::testFeatures with data set "Methods\Builder.php" ('E:\Code\Package\larastan\test...er.php')
null
E:\Code\Package\larastan\tests\FeaturesTest.php:43
E:\Code\Package\larastan\tests\FeaturesTest.php:33
2) Tests\FeaturesTest::testFeatures with data set "Methods\CarbonExtension.php" ('E:\Code\Package\larastan\test...on.php')
null
E:\Code\Package\larastan\tests\FeaturesTest.php:43
E:\Code\Package\larastan\tests\FeaturesTest.php:33
3) Tests\FeaturesTest::testFeatures with data set "Methods\Contracts.php" ('E:\Code\Package\larastan\test...ts.php')
null
E:\Code\Package\larastan\tests\FeaturesTest.php:43
E:\Code\Package\larastan\tests\FeaturesTest.php:33
4) Tests\FeaturesTest::testFeatures with data set "Methods\Facades.php" ('E:\Code\Package\larastan\test...es.php')
null
This is for test 47
47) Tests\Rules\NoUnnecessaryCollectionCallRuleTest::testNoFalseNegativesQuery
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 0 => 'Called 'max' on Laravel colle...query.'
- 1 => 'Called 'isNotEmpty' on Larave...query.'
- 2 => 'Called 'pluck' on Laravel col...query.'
)
if uses vendor/bin/phpunit --debug --stop-on-defect

Please debug the output of sprintf here
maybe with error_log();

Like this? I'm using dump
Yes. The complete return value of sprintf, the whole command line.
I got this
"C:\laragon\bin\php\php-7.4.5\php.exe" E:^\Code^\Package^\larastan^\tests/../vendor/bin/phpstan analyse --no-progress --level=max --configuration "E:\Code\Package\larastan\tests/../extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php" --error-format=json
Does it run?
So this produces the null?
I think we don't support MINGW64, only pure Windows.
Does it run?
So this produces the null?
TBH I dont know whether that is the cause that produces the null or not.
I think we don't support MINGW64, only pure Windows.
I tried using Windows PowerShell and CMD both also same.


"C:\laragon\bin\php\php-7.4.5\php.exe" E:^\Code^\Package^\larastan^\tests/../vendor/bin/phpstan analyse --no-progress --level=max --configuration "E:\Code\Package\larastan\tests/../extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php" --error-format=json
This is highly abnormal in my eyes.
See #682!
I tried pull the PR 682, and still not solves my issue.
When dump the sprinf I got this
"C:\laragon\bin\php\php-7.4.5\php.exe" E:^\Code^\Package^\larastan/vendor/bin/phpstan analyse --no-progress --level=max --error-format=json --configuration="E:\Code\Package\larastan\tests/../extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php"
Could you actually run the dumped value thus command?
If not what to modify in it?
Could you actually run the dumped value thus command?
If not what to modify in it?
Using Latest PR from #682
I got this value from sprint f
"C:\laragon\bin\php\php-7.4.5\php.exe" E:^\Code^\Package^\larastan/vendor/bin/phpstan analyse --no-progress --level=max --error-format=json --configuration="E:\Code\Package\larastan/extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php"
Result after I run above code

Then I modify it to be like this
"C:\laragon\bin\php\php-7.4.5\php.exe" "E:\Code\Package\larastan/vendor/bin/phpstan" analyse --no-progress --level=max --error-format=json --configuration="E:\Code\Package\larastan/extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php"
and try run it and got this

I saw this issue, and try follow remove the php command as said they said here. Then I got the output like this

@szepeviktor I update execLarastan function to be like this
public function execLarastan(string $filename)
{
$command = escapeshellcmd(dirname(__DIR__).'/vendor/bin/phpstan');
exec(
'"E:\Code\Package\larastan/vendor/bin/phpstan" analyse --no-progress --level=max --error-format=json --configuration="E:\Code\Package\larastan/extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php"',
$jsonResult
);
return json_decode($jsonResult[0], true);
}
Then I run PHPUnit, only got 7 failures. Before this 47 failures.

Thank you for your digging!
BTW Do you know how to detect MINGW64? Maybe by PHP_OS and PHP_OS_FAMILY ?
馃 https://github.com/laravel/framework/blob/8.x/src/Illuminate/Support/helpers.php#L361
with https://github.com/symfony/polyfill/pull/88/files#diff-727b896b488311033dc285a4e254f96bR65-R83 on PHP 7.1 -> already included in symfony/polyfill-php72 which is our depencency
This rabbit hole is very deep https://www.php.net/manual/en/function.escapeshellarg.php#123718
You should not get funky stuff like E:^\Code^\Package^\larastan/vendor/bin/phpstan on MINGW64.
Surprisingly this works in cmd.exe: C:^\Windows/explorer.exe :)
This rabbit hole is very deep https://www.php.net/manual/en/function.escapeshellarg.php#123718
You should not get funky stuff like
E:^\Code^\Package^\larastan/vendor/bin/phpstanon MINGW64.Surprisingly this works in cmd.exe:
C:^\Windows/explorer.exe:)
Yup can confirm that C:^\Windows/explorer.exe work in cmd.exe. So I update execLarastan method like below. Then try run it in cmd.exe
public function execLarastan(string $filename)
{
$command = escapeshellcmd(dirname(__DIR__).'/vendor/bin/phpstan');
exec(
'E:^\Code^\Package^\larastan/vendor/bin/phpstan analyse --no-progress --level=max --error-format=json --configuration="E:\Code\Package\larastan/extension.neon" "E:\Code\Package\larastan\tests\Features\Methods\Builder.php"',
$jsonResult
);
return json_decode($jsonResult[0], true);
}
Then I got same 7 failures as before. I still need to remove "C:\laragon\bin\php\php-7.4.5\php.exe" at front of the command though.
Without PHP at front

With PHP at front

@szepeviktor is it possible that my PHP environment problem? maybe need someone to test on their windows OS whether they have same issue like me or not.
From where do you have PHP MINGW64? Have you compiled PHP yourself?
I uses MINGW64 because I set Git Bash as default terminal in my vscode. I did not compile PHP by myself, I just download it and put it inside Laragon.
PHP 7.4.11 (cli) (built: Sep 29 2020 13:17:42) ( NTS Visual C++ 2017 x64 )
from windows.php.net says:
C:\usr\php>php -r "echo PHP_OS;"
WINNT
C:\usr\php>php -r "echo PHP_OS_FAMILY;"
Windows
@xitox97 Please run
php path\to\composer run-script test:unitwith this branch....not really Windows junctions: Composer substitutes
vendor/bin/*symlinks on Windows with POSIX shell scripts._Originally posted by @szepeviktor in https://github.com/nunomaduro/larastan/pull/682#issuecomment-706689568_
If I run with PHP infront

If without PHP, I got the 7 failures. I think there is improvements than before where I run got 47 failures.

Edit: I tested both in cmd.exe and MINGW64
Edit: I tested both in cmd.exe and MINGW64
Thank you!
Have you pulled the recent changed from my branch?
Got it!
Composer uses symlinks on POSIX-compat OS-es
and POSIX shell scripts on Windows :(

Your path to the Composer tool seems to be such a POSIX shell script.
Please run php path\to\REAL\PHAR-FILE\composer run-script test:unit
Edit: I tested both in cmd.exe and MINGW64
Thank you!
Have you pulled the recent changed from my branch?
Yup I already pull your latest changes.
@szepeviktor so I run using this command php C:\ProgramData\ComposerSetup\bin\composer.phar run-script test:unit and it does show stop at php "${dir}/composer.phar" "$@" anymore.
However, I still got 7 failures.

All right! 馃帀
We have a solution.
Please open a separate issue if you are curious about those model property tests. I am!
@szepeviktor Wow. You are legend! :heart_eyes: TQVM. I will open seperate issue for the model property tests. Should I wait for the PR merged first?
Should I wait for the PR merged first?
No, just open that issue.
Please try to fix the failing tests before that!
Most helpful comment
All right! 馃帀
We have a solution.
Please open a separate issue if you are curious about those model property tests. I am!