PHPUnit test suite fails on Windows

[sun]

PHPUnit's own test suite has various failures on Windows currently. There are two dominant causes:

1. DIRECTORY_SEPARATOR mismatches in PHPT tests.
2. Expected stack traces in PHPT tests do not account for an additional stack frame that is caused by PHPUnit_Util_PHP_Windows::process().

Lastly, there's a difference in libxml behavior with regard to PHPUnit_Util_XML::load() on Windows, which causes configuration.xml tests to fail, because relative file paths are not resolved correctly - they're resolved base on the current working directory, instead of the directory in which the configuration file is contained; setting DOMDocument::$documentURI does not help in any way (but is required and MUST be set before loading the XML for XInclude to work).

[sun]

This might be the only debatable change.

Technically, it not only hides the process isolation script from stack traces, but any PHP code that happens to be executed through a temporary file in the temporary directory.

However, even on the assumption that such an edge case exists in the wild in the first place, then additional stack frames like the following are not exactly helpful anyway:

C:\Users\sun\AppData\Local\Temp\PHP4B92.tmp:323
C:\Users\sun\AppData\Local\Temp\PHP4B92.tmp:444

That's why I added the system's temporary directory to the blacklist instead.

Before doing this change, I considered two alternatives:

1. Changing PHPUnit_Util_Filter to remove the last stack frames, if their file paths point to the temp directory.
2. Adjusting all PHPT tests to include an %A where stack traces are asserted in the output, so as to account for the two additional frames on Windows.

(2) would be cumbersome to maintain + tests would be guaranteed to break on Windows in the future again. (1) sounds nice, but requires relatively complex code to introspect each stack trace.

Therefore, I went with this KISS solution.

[whatthejeff]

Seems like you could also add the following to PHPUnit_Util_Blacklist::isBlacklisted():

if (DIRECTORY_SEPARATOR === '\\' && 
    strpos($file, sys_get_temp_dir() . '\\PHPUnit') === 0) {
    return true;
}

[sun]

strpos($file, sys_get_temp_dir() . '\\PHPUnit') === 0

To quote the PHP manual:

Note: Windows uses only the first three characters of prefix.

The temporary file names are still compatible with filesystems that only support 8.3 filenames.

We can minimally adjust it and append 'PHP' to the blacklisted pathname (which are checked via strpos() anyway), although the likelihood of a prefix-clash would be relatively high, because 'PHP' is a fairly generic prefix for PHP software. 😉

But yeah, let me do that, so as to do the maximum to avoid false-positives.

[whatthejeff]

Hard to say what the likelihood of a clash would be without some sort of empirical data. If we really believe it's an issue, we could always add an interface for supplying the exact filenames to blacklist.

[sun]

I've included the prefix now.

[whatthejeff]

This looks good to me (outside of the line note I left you).

[whatthejeff]

Thanks!

[sun]

Thanks a lot! This allows me to properly debug the real/remaining failures of #1352 :)