You may have a unit test that makes assertions about logs though? I would definitely expect somebody that isn't a junior programmer to understand this.
I don't think your explanation is compelling.
> a log is just some subsystem of your overall program that prints some output with no pass/fail condition.
The pass fail is interpreted. A unit test result is interpreted, be it with a big green/red or an exception or any other way you wish to express it.
Running something manually and checking the logs in an environment, when there is a reported issue, is modus operandi of every developer today. Did A happen and B happen and what did C say before exit? A looks good (because it has an expected state), etc.
> I would definitely expect somebody that isn't a junior programmer to understand this.
I didn't say logs were a replacement for unit tests (that's a previous poster's strawman). Regardless, they are a form of testing, because we use them to observe state after execution. Manual testing is testing, manual testing and observation of logs, is testing.
I would say "Observe the state of an execution stack". Tomato tomato.
> which has a very specific meaning
Unit testing is a methodology, not a specific thing.
How you observe it, be it through a pass fail indicator or a "This looks right", is immaterial. Splitting hairs on the output methodology does not change the utility.
This can also be a great way to write your unit tests. Once you like what your code does in some situation, you can copy paste the input and expected output into a unit test to make sure you don’t break that correct behaviour later.
When there's too much noise it becomes harder to see what's happening.
You can turn down the log level but then you loose that visibility altogether.
Executing a suite requires a manual interaction (ie > run suite or > make build -> runs suite or > edit cron -> runs suite). In a way, all testing is still manual, but test suites allow us to scale testing, which logs do not (1million log files is impractical to use as testing output). That's why unit test frameworks are a good thing.