I do agree with Steve that you should test your logging interfaces to make sure they behave correctly, but if I understood your question, you're more focused with testing the log output itself.
I think that depends on use cases but in my use case and domain, what the logs capture is actually a "last-resort option" for issues that escape testing. If some bug flies under the radar and a user crashes somewhere, for example, their log shows us what the system was doing when they crashed which significantly narrows the list of suspects (unless, of course, the log output is wrong/misleading which is probably what you're trying to avoid, but that seems so out of the way to me to test).
So it seems rather redundant in my case to test the output of the logs themselves, since in an ideal world we wouldn't need them. They're a last resort measure, and have been a lifesaver in some contexts (one time I was able to quickly narrow down that a user's hardware didn't have support for SSE 4, even though we listed it in our requirements, by looking at his log combined with hardware requirements; absent the logs I might have spent a week bouncing builds back and forth with him to try to narrow down where he crashed). And we solved that by at least making the code detect that hardware limitation and report it to the user instead of crashing*
Though we had to bear the bad news that he did not pay attention to our minimum hardware requirements; he was using some obscure prototype machine we never heard of which still didn't support SSE 4 in 2013 in spite of having 24 cores and 64 gigs of DRAM. Later, out of sympathy, I actually spent a weekend porting the code to use SSE 2 in those cases to reduce our minimum requirements since I figured he must have invested enormous sums of money for that prototype hardware even though there wasn't a legit business requirement. It made me sad to think a person with such beefy hardware couldn't run our software because of this restriction.
But in an ideal world I wouldn't lean on the logs for such ad-hoc debugging; all such issues would be caught in our tests. But I can't always depend on our tests for that, especially with varying hardware capabilities (when our team, including QA, doesn't have all the hardware in the world to test against, even though they have a wide range). Yet testing the log output would be quite a time sink with probably little gain for an issue that ideally should have been caught absent the logs in the first place.
For my domain (and I don't expect everyone to be the same here), we treat logging like a "non-side effect". That is to say, we don't unit test functions to make sure their implementations write the "correct" things to logs as part of the functional requirements, because that would double up our testing efforts for something designed to catch what eludes our tests in the first place. Even "correct" logging isn't that interesting in our case, provided it's not redundant. If some subsystem writes, "I'm doing backflips and eating pizza!" which doesn't describe, very well, what they're actually doing, as long as no other systems are writing that same info, it still lets us trace down exactly what the software was doing before it crashed or glitched out.
We do, however, have tests designed to make sure the logging functionality itself works, and across threads, and against varying exceptions. But that's separate from testing the logging output of every single thing that utilizes logging.