Hacker News Reader

Comment by Supermancho | Hacker News Reader

A jr programmer once asked how I know that N lines do what I expect without writing a test every 10 minutes. Logging is a form of unit testing. Logging can be thought of as unit tests for your specific context, decoupled from the logic (almost) entirely.

I have an expectation of state, the execution can be checked against that expectation via observation of the output (which usually has serialized state). It's not a fancy True False or checkmark, but it's an assertion (which constitutes a test of an expected state) nonetheless.

View on HN

There are two junior developers in your anecdote. That’s not a test. It’s not even comparable to unit tests, much less a replacement for them.

If you want to define tests as something other than observed state, go ahead. The ad hominem looks like you took it personally.

A log statement isn't a unit test in the same way that apples aren't trees. A unit test is a discrete, runnable program that asserts some state about your program to be true, whereas a log is just some subsystem of your overall program that prints some output with no pass/fail condition.

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.

> A log statement isn't a unit test in the same way that apples aren't trees

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.

You explicitly said logging is a form of "unit test" which has a very specific meaning and a log is not it. Observing a log can obviously be part of an assertion in a test be it manual or whatever, but an assertion is not a unit test.

> A unit test is a discrete, runnable program that asserts some state about your program to be true

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.

The difference is that unit tests are checked automatically, and logs require manual inspection.

Eyeballing a log is often enough to convince myself that some code is probably correct. It’s not as thorough as a unit test, but better than nothing if you weren’t planning on writing a test anyway.

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.

The other difference is that unit tests are usually quiet unless something is wrong but log statements are always noisy.

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.

Unit test frameworks are the modern, convenient, methodology to control bubbling up an output, when multiple assertions fail. This is what observing the red (suite failed) or green (suite succeeded) is.

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.

Reply on news.ycombinator.com