No test can read a log line, and two changes in a row have turned on one

#574 · open · 0 comments

View on GitHub ↗

akiomik

Raised from [#573](https://github.com/akiomik/nostui/pull/573), where it stopped a fix from being verifiable. Not that PR's doing. ## What is missing Nothing in this repository asserts log output. Measured rather than assumed: gutting the log line in `report_publish_failure` so it no longer names the publish — which is exactly the defect #571 filed — leaves all 424 unit tests green. ## Why it has started to matter Two consecutive changes have had a log line as the behaviour under change rather than as a by-product: - [#570](https://github.com/akiomik/nostui/pull/570) — the blank-draft refusal called a reply a note in the log after the bar had stopped. - [#573](https://github.com/akiomik/nostui/pull/573) — a failed publish did not say in the log which kind of publish had failed. Both are carried by reading. That is not an accident of those changes: the log is deliberately part of how this program is diagnosed. `submit_note` keeps a refusal at `warn` and says why in a comment — so that "Ctrl+P did nothing" can be triaged by grepping at warn and above — and the status bar holds one line that the next status overwrites, so the log is what a report is reconstructed from. Behaviour that is designed to be read is behaviour worth asserting. ## What makes it awkward `log::set_logger` takes effect once per process and tests run in parallel in one, so a capturing logger is global state shared by every test in the binary. Whatever is built has to let one test read its own lines without the rest of the suite writing into them — by serialising the tests that assert, by filtering on something that identifies the emitting test, or by some third thing. That cost is the reason this is a question rather than an obvious yes. `CONTRIBUTING.md` says a red coverage mark beats a contrivance that buys the percentage back, and a harness nobody can use twice would be one. It is worth building only if asserting a log line ends up reading as plainly as asserting the status bar does. ## Acceptance - A test can assert that a given call writes a given log line, and fails when it does not. - Tests that do not assert logs are unaffected by ones that do, in any order and in parallel. - The failures above — a reply logged as a note, a publish failure that does not name its kind — each have a case that fails without the fix.

Comments