symbolic link trouble + PHPUnit unknown #778
Comments
|
Could you run infection with the Also, what happends when you run infection from the root of the project, instead of the test sub directory? |
No change there. Did notice that the composer bin sometimes generates with an absolute path on either phpunit or infection (completely randomly), but that's probably a composer issue from what I can find: composer/composer#5427. Even changing these to the proper relative paths doesn't change the output:
Debug output, subfolder (under symlink)Output from root, actualOutput from root, symlink |
|
Steps to reproduce: The last command outputs: |
|
Removing <phpunit colors="true"
verbose="true"
- stderr="true"
beStrictAboutOutputDuringTests="true">It is PHPUnit that exits with 143, do I don't think this is the exact problem of Infection. But it may make sense to remove this directive in our configuration file because we certainly do not need it. https://phpunit.readthedocs.io/en/8.3/configuration.html#the-stderr-attribute
|
|
Does it mean that PHPUnit exits with non-zero code even if tests pass?
Sounds good 👍 |
|
It didn't go as far as running tests, as I see it. |
|
@sanmai The issue seems to be the <project source> in coverage-xml/index.xml. When phpunit is run from either the actual or symbolic link directory, this is always the real path. Changing project source to the symbolic path makes the symbolic link run work and actual directory run fail (and vice versa). Tested with both PHPUnit 7.5.16 and 8.3.5. To reproduce: *For instance: If the actual directory is C:\Apache24\htdocs\infection-temp, <project source="C:\Apache24\htdocs\infection-temp"> should be what shows up in the index.xml file (regardless of run location). If the sym link is C:\Apache24\htdocs\infection-test, change <project> source to C:\Apache24\htdocs\infection-test and infection should succeed when run in the symbolic link directory. Note that this will cause it to skip mutants if run from the actual directory. tl;dr - The hard-coded path in coverage-xml/index.xml is what seems to be causing the problem. |
|
If you could make a reproducible case like I did above, this will be a big help. So far I cannot reproduce the issue, and I have my development copy of Infection symlinked from elsewhere, with no problems whatsoever.
…--
Alexey
On Tue, Sep 17, 2019, at 20:07, Chris Richard wrote:
@sanmai <https://github.com/sanmai>
Removing stderr didn't work for me -- output came out the same (killed in actual directory, not covered in symbolic). But that got me thinking:
The issue seems to be the in coverage-xml/index.xml. When phpunit is run from either the actual or symbolic link directory, this is always the real path.
Changing project-source to the symbolic path makes the symbolic link run work and actual directory run fail (and vice versa).
Tested with both PHPUnit 7.5.15 and 8.3.5.
Hope that helps. XD
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#778?email_source=notifications&email_token=AABCBYH4YD37UXBWDJFCPZLQKC265A5CNFSM4ISUUXJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD64FGKQ#issuecomment-532173610>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCBYBBNU3GA32KCEWV5R3QKC265ANCNFSM4ISUUXJA>.
|
sanmai
added
Waiting Response
and removed
PR merged
Good First Issue / Easy Pick
labels
@sanmai Added in previous comment. |
Can you show a diff to this change? Where should the symbolic link point? |
|
In this case, the actual directory is: Symbolic link is: PHPUnit generated `tmp/coverage-xml/index.xml` from actual directory:PHPUnit generated Making the following change lets it pass under the symbolic link, though mutants are skipped on the actual directory then.<?xml version="1.0"?>
<phpunit xmlns="https://schema.phpunit.de/coverage/1.0">
<build time="Thu Sep 19 1:25:37 GMT+0000 2019" phpunit="7.5.16" coverage="6.1.4">
<runtime name="PHP" version="7.3.5" url="https://secure.php.net/"/>
<driver name="xdebug" version="2.7.2"/>
</build>
- <project source="C:\Apache24\htdocs\infection-temp\lib\App\src">
+ <project source="C:\Apache24\htdocs\infection-test\lib\App\src">
<tests>
<test name="Test\CodeTest::getTest_returns_boolean" size="unknown" result="0" status="PASSED"/>
<test name="Test\CodeTest::getTest_returns_constructed_value" size="unknown" result="0" status="PASSED"/>
</tests>
<directory name="/">
<totals>
<lines total="20" comments="0" code="20" executable="3" executed="3" percent="100.00"/>
<methods count="2" tested="2" percent="100.00"/>
<functions count="0" tested="0" percent="0"/>
<classes count="1" tested="1" percent="100.00"/>
<traits count="0" tested="0" percent="0"/>
</totals>
<file name="Code.php" href="Code.php.xml">
<totals>
<lines total="20" comments="0" code="20" executable="3" executed="3" percent="100.00"/>
<methods count="2" tested="2" percent="100.00"/>
<functions count="0" tested="0" percent="0"/>
<classes count="1" tested="1" percent="100.00"/>
<traits count="0" tested="0" percent="0"/>
</totals>
</file>
</directory>
</project>
</phpunit>As for where it should point, I'm not sure. /src/TestFramework/PhpUnit/Coverage/CoverageXmlParser.php line 227 seems to be where it's having trouble, but I haven't looked over the code-base well yet and couldn't say for sure. |
|
Why would you want to change that file? |
|
The coverage-xml file? I wouldn't. Your command when you ran infection and got the 143 error, then the stderr setting got me thinking on trying to figure out where the problem was originating, which seems to be the absolute/hard-coded directory in project source within coverage-xml/index.xml. |
|
Well, it is kind of obvious that if you change things from under Infection, it'll go haywire. This is not the issue we can fix, because one should not change said files in the first place. If you don't have the issue with the dev version of Infeciton, let's close this. Else, please give us something so we can reproduce the issue. Install the dev version as follows: |
Infection dev version, actual directory:With the dev branch under the symbolic link:Issue exists with the dev branch. To be clear: I didn't change the index.xml file until trying to figure out why when I mentioned this first, two comments back:
Changing the xml file is what led me to determine that the absolute path in project source within it may be the issue (which is always the real path, even under a symlink run of PHPUnit). Since the project source is the absolute path, when infection runs, it doesn't seem to be finding the tests, since they're in a different (absolute) path. *updated output with --debug (sorry, missed that command) |
Isn't that kind of expected? If you symlink something into entirely different hierarchy where you can't see the previously seen tests directory, then you obviously have no tests PHPUnit-wise, and no coverage too. Which is exactly what Infection is trying to say you: nothing is covered by tests. The other question is why #602 didn't trigger. |
|
If the entire directory structure is under a symbolic link (as it is for this), the tests are there (as is the code). PHPUnit finds it all, since it's there, but generates the coverage-xml/index.xml file with the actual (absolute) path, instead of the symlink. Infection isn't finding those tests, because it's looking under the actual (absolute) path, which either doesn't match the current path and is ignored (?) or something else strange is going on. Make sense? Or am I explaining this badly? Or, since the files covered by tests are in the actual directory (according to the coverage-xml/index.xml file), Infection is saying the symlink src isn't covered, since the index.xml tests are pointing to the real files, instead of the ones under the symlink. (Maybe?) |
|
If I do like this: The output is absolutely the same. Two layers of symlinks here if you note. Can you tell exactly which symbolic links you make? Best if as in a script. |
|
Mine are (Windows, unfortunately): In this case, it ends up with: With everything in the repository below that. If it helps, I can test it in Linux to see if I get the same output you are. It could be, in part, a Windows issue. |
|
Thank you for explaining the issue. With the same setup I cannot reproduce the exact issue under Linux, unfortunately. I'll keep trying though. |
|
@sanmai Anytime. XD I'll check in Linux, too, see if it's purely a matter of the paths generated in Windows runs and let you know (probably tomorrow). |
|
@sanmai It seems like it's just a Windows symbolic link problem. Had to add a new test to make it so that no mutants escaped (using the dev branch on Linux), but you're right -- symbolic links all worked fine. Let me know if you all need any additional log data or for me to check into anything on this end. |
|
I've a similar issue which might have the same root cause. I nailed it down to the But it is also a blocker for me, as this prevents functional test setup with TYPO3 CMS. You can use DanielSiepmann/tracking@41eb616 as a state to reprocude the issue. The associated action run is failing for that reason: https://github.com/DanielSiepmann/tracking/actions/runs/198375140 TYPO3 internally will remove file system files and checks for symlinks to unlink instead of remove. Due to the setup it will remove the project files themselves, as they are symlinked. |
|
That one is working for me, maybe someone can have a look, check and merge + release? :) Hopefully it will solve the issue: infection/include-interceptor#14 |
|
Please check if the current master solves this issue. |
|
Happened to be checking back on this to delete the repository. The original issue is resolved (tested in both php 7.3 and 8.0). Thanks, all! |
When run under a symbolic link in a terminal, infection creates all of the mutants, but claims they're all uncovered by tests.
To reproduce:
Repository above contains samples and structure if you want it.
Infection was run from the test subdirectory with:
Separate issue is that the PHPUnit version is unknown, both in the symlink folder and the actual one. (Whether vendor/bin directory is or isn't in PATH.)
Left out the phpunit.junit.xml for brevity (and since it's probably not relevant).
Output with issue
The text was updated successfully, but these errors were encountered: