Closed gabfr closed 4 years ago
Could you run php -S localhost:8086
and curl localhost:8086
to see if that is just PHP’s webserver emitting these log messages?
Hello, i have the same problem here. This is the output of php:
[Sun Feb 23 10:18:31 2020] PHP 7.4.2 Development Server (http://localhost:8086) started
[Sun Feb 23 10:18:43 2020] [::1]:55146 Accepted
[Sun Feb 23 10:18:43 2020] [::1]:55146 [404]: (null) / - No such file or directory
[Sun Feb 23 10:18:43 2020] [::1]:55146 Closing
Alright. This shows that it is a functionality of the built in web server. We probably need to filter out expected logs in http mock. Anybody feels like looking into a patch?
I currently write a small fix. it look somewhat like this:
// ...
public static function assertSuccessFullPhpServerOutput($output, $message='')
{
foreach (explode("\n", $output) as $line) {
if (static::isPhpServerErrorOutputLine($line)) {
static::fail($message ?: "PHP Web Server logged an error: $line");
}
}
}
public static function isPhpServerErrorOutputLine($line)
{
if (!$line) {
return false;
}
$endsWith = function ($haystack, $needle) {
return substr($haystack, -strlen($needle)) == $needle;
};
return !$endsWith($line, 'Accepted') && !$endsWith($line, 'Closing') && !$endsWith($line, ' started');
}
// ...
But I doubt the string comparison stuff is a good solution in general...
If we need to go down the route, your code looks good. Does passing -q
or —quiet
or sth similar change the picture?
I created a pull request with another similiar solution. I just filter the non-error lines out before returning them. I played a little with your unit tests and this worked better (created less diff) then the other approach. The Travis builds show that it works in PHP 7.1-7-3 too but the builds are failing. Somebody should also add PHP 7.4 in the travis file.
If we need to go down the route, your code looks good. Does passing
-q
or—quiet
or sth similar change the picture?
The -q
option did not worked here to suppress those server log statements. From the PHP docs it does layoff only the headers (https://www.php.net/manual/en/features.commandline.options.php).
I created a pull request with another similiar solution. I just filter the non-error lines out before returning them. I played a little with your unit tests and this worked better (created less diff) then the other approach. The Travis builds show that it works in PHP 7.1-7-3 too but the builds are failing. Somebody should also add PHP 7.4 in the travis file.
I made a PR to a fork version of this repo that we maintain here at Linio and added 7.4 to the travis file. Everything went good.
@gabfr Looks very good. I wanted to clean up my PR but saw your work. I just added one request for change to your own PR. Then I think its perfect and we can close my PR here.
@mtils do you feel like updating your PR with the same changes of mine? or should I submit another?
@gabfr I think it is better if you create a PR of your changes. You're changes are now well tested. I will close mine then. This is terrific team work ;-)
Thanks guys for the help into this solution!
Hello!
After I updated my project to use PHP 7.4, now when I try to run my integration tests I always get a very weird output from the
stderr
pipe when runningHttpMockTrait::tearDownHttpMock();
:All my tests are failing because of the same error. If I stop calling the
$this->tearDownHttpMock();
, then the tests starts passing.Someone else is experiencing this too? It's happening only after I updated the PHP version. This is some kind of new behavior of Php? Shouldn't this output be directed to the
stdout
pipe instead of thestderr
? I mean, these are not errors, they're just logs in fact.I'm not even sure if the issue is with
internations/http-mock
orsymfony/process
, so, I'm sorry if this issue isn't in the correct place.