starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-27 08:35:53 +03:00

[GH-ISSUE #1856] Is it possibile to log to the stream that is completely outside of the application environment? #794

New issue

Closed

opened 2026-03-04 02:18:01 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 02:18:01 +03:00

Owner

Originally created by @ghost on GitHub (Nov 16, 2023).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1856

Monolog version 1|2|3?
2 or 3

Intro
Let's say we have tests where some code is executed outside of the tests context, e.g.:

API testing where there is a running server and real http requests are executed against it
console commands executed via shell_exec (or something). Here we could probably check the exit code in tests but some commands are not "all or nothing" commands or are designed to be daemons that don't exit on exceptions (e.g. message consumers).

Unfortunately the app code and the tests are not perfect, developers are also on different levels and many don't follow TDD approach what leads to the following problem.

The problem
The problem is that some tests are green even though the server logs have errors. This is because some errors are silenced and logged (what is fine) or, in case of deamon commands, are only logged. However this s not what the test is testing so these errors are missed.

The need
I would like to have a handler in my application that can log to the console where I'm executing tests. Something like this:

$ vendor/bin/phpunit
# the tests are running, API calls are executed, console commands run on the background

# logs from the API server/console commands are shown here

It could be great if the handler in my application would somehow connect to the shell (and it's stdout/stdin) where the test framework is running. This way a developer could see the errors and react despite of the tests being green.
One idea that I have is whether PHP can write to the file descriptor. A terminal where tests are running has it's own process number so if we somehow got this number in the running application we could log to it's file descriptor no. 1.

P.S. yes, I know developers could open the logs file from the application and follow it but: 1. logs from all the test runs would be three so searching is difficult; 2. unfortunately the devs ignore log file until the tests are not green.

Originally created by @ghost on GitHub (Nov 16, 2023). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1856 Monolog version 1|2|3? 2 or 3 **Intro** Let's say we have tests where some code is executed outside of the tests context, e.g.: - API testing where there is a running server and real http requests are executed against it - console commands executed via shell_exec (or something). Here we could probably check the exit code in tests but some commands are not "all or nothing" commands or are designed to be daemons that don't exit on exceptions (e.g. message consumers). Unfortunately the app code and the tests are not perfect, developers are also on different levels and many don't follow TDD approach what leads to the following problem. **The problem** The problem is that some tests are green even though the server logs have errors. This is because some errors are silenced and logged (what is fine) or, in case of deamon commands, are only logged. However this s not what the test is testing so these errors are missed. **The need** I would like to have a handler in my application that can log to the console where I'm executing tests. Something like this: ```bash $ vendor/bin/phpunit # the tests are running, API calls are executed, console commands run on the background # logs from the API server/console commands are shown here ``` It could be great if the handler in my application would somehow connect to the shell (and it's stdout/stdin) where the test framework is running. This way a developer could see the errors and react despite of the tests being green. One idea that I have is whether PHP can write to the file descriptor. A terminal where tests are running has it's own process number so if we somehow got this number in the running application we could log to it's file descriptor no. 1. P.S. yes, I know developers could open the logs file from the application and follow it but: 1. logs from all the test runs would be three so searching is difficult; 2. unfortunately the devs ignore log file until the tests are not green.

kerem

2026-03-04 02:18:01 +03:00

closed this issue
added the
Support
label

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

You should be able to use a StreamHandler with php://stdout or php://stderr as URL?

@Seldaek commented on GitHub (Apr 12, 2024): You should be able to use a StreamHandler with php://stdout or php://stderr as URL?

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@ghost commented on GitHub (Apr 12, 2024):

php://stdout (or err) is the stream for the running process, right? I would like to use a stream from another process. Example:
In first terminal:

# start the web server (this could be also an fpm docker image running)
$ php -S 127.0.0.1 index.php
# this terminal is a php://stderr for the web server

In second terminal:

# run api tests that send api calls to web server
$ vendor/bin/phpunit
# this terminal is a php://stderr for the unit tests

I would like to send logs also to the second terminal.

@ghost commented on GitHub (Apr 12, 2024): php://stdout (or err) is the stream for the running process, right? I would like to use a stream from another process. Example: In first terminal: ```sh # start the web server (this could be also an fpm docker image running) $ php -S 127.0.0.1 index.php # this terminal is a php://stderr for the web server ``` In second terminal: ```sh # run api tests that send api calls to web server $ vendor/bin/phpunit # this terminal is a php://stderr for the unit tests ``` I would like to send logs also to the second terminal.

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

Ah I see.. then IMO the next best thing might be to have a step after phpunit is done that checks the test log file and outputs anything that's in it if present.. There are for sure other options to communicate between processes but that doesn't really seem worth the hassle here to have a custom handler talking to the phpunit process etc.

@Seldaek commented on GitHub (Apr 12, 2024): Ah I see.. then IMO the next best thing might be to have a step after phpunit is done that checks the test log file and outputs anything that's in it if present.. There are for sure other options to communicate between processes but that doesn't really seem worth the hassle here to have a custom handler talking to the phpunit process etc.

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@ghost commented on GitHub (Apr 12, 2024):

Good idea. With this solution one more thing that's required to do is to create a single file per one test run. Will check if RotatingFileHandler can be configured for that.
Or empty the file before tests start.

@ghost commented on GitHub (Apr 12, 2024): Good idea. With this solution one more thing that's required to do is to create a single file per one test run. Will check if RotatingFileHandler can be configured for that. Or empty the file before tests start.

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

Yeah I'd empty it in the tests bootstrap, keep it simple.

@Seldaek commented on GitHub (Apr 12, 2024): Yeah I'd empty it in the tests bootstrap, keep it simple.