Timeline for Should I use a global logging variable?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 15, 2023 at 17:51 | comment | added | Doc Brown | @Basilevs: exactly what I wrote in my answer - when your program starts to become larger, your testing requirements increase, and then there will be a point where a global variable for a logger starts to make trouble. | |
| Jul 15, 2023 at 14:50 | comment | added | Basilevs | @DocBrown logging initialization on the start of the program precludes isolated tests, as different units would dereference different loggers (due to mutability of global logger) depending on their initialization timings. Also, using global logger for tests makes it harder to isolate logging events from different units in integration tests. | |
| Jul 15, 2023 at 7:25 | comment | added | Doc Brown | @Ben: the logs from the "testing process itself" will be created by some logger of your testing framework, which is unlikely to be the same logger object in ones own code. This completely irrelevant to "global variable vs DI". | |
| Jul 15, 2023 at 3:26 | comment | added | Ben | @DocBrown Such as having logging functionality in the testing process itself, while treating logs emitted from the unit-under-test differently (those logs may well be the functionality some of the test cases cover) | |
| Jul 14, 2023 at 12:45 | comment | added | Doc Brown | Your overall answer is ok, but your second bullet point is, to be honest, plain wrong. Using different loggers for tests and production will be equally simple, regardless if one initializes a global variable with a specific logger at the program's start, or if one uses DI for this. What really becomes difficult is to use different loggers for different objects within the same execution context. | |
| Jul 14, 2023 at 7:21 | history | answered | sfiss | CC BY-SA 4.0 |