Skip to content

Add logging module tests and raise coverage threshold to 68%#147

Open
bedus-creation wants to merge 4 commits into
mainfrom
task/logging-coverage-68
Open

Add logging module tests and raise coverage threshold to 68%#147
bedus-creation wants to merge 4 commits into
mainfrom
task/logging-coverage-68

Conversation

@bedus-creation

Copy link
Copy Markdown
Contributor

Summary

Adds real unittest-style tests for the logging module and raises the pytest-cov minimum coverage threshold from 50 to 68. Ships tasks #675 and #674 together so coverage is measured with the new tests present.

Changes

  • tests/logging/test_logging.py — new test suite (50 tests) exercising the actual logging module:
    • LogProvider register/boot: factory + manager bindings, config merge, logger channel swap, early-return when no default channel
    • ChannelFactory / DriverFactory name→class resolution and unknown lookups
    • BaseDriver.should_run level-severity filtering
    • BaseChannel / MultiBaseChannel / StackChannel delegation and level thresholds
    • Drivers: terminal (stdout), single (file output), slack (mocked HTTP), syslog (mocked handler)
    • Logger facade: level delegation, log() dispatch + fallback, caller location
    • LoggingManager / LoggingHandler install idempotency and record forwarding
    • make_directory, config dataclass defaults, exception listener
  • pyproject.tomlfail_under 50 → 68

The suite installs a global LoggingHandler during setup; the module fully restores root-logger and app state in teardown so no state leaks into other test modules.

Verification

uv run pytest --cov --cov-report=term-missing (from fastapi_startkit/):

  • Total coverage: 71.25% (≥ 68% threshold reached)
  • logging module goes from 0% to ~85% overall
  • All non-postgres tests pass (1648 passed). The 17 failures are the pre-existing tests/masoniteorm/postgres tests that require a live Postgres connection (documented --ignore=tests/masoniteorm/postgres), unrelated to this change.

…to 68%

Add unittest-style tests covering the logging module: LogProvider
register/boot, channel and driver factories, level filtering, the
Log facade, channels, drivers, handler installation, and config
defaults. Raise pytest-cov fail_under from 50 to 68; total coverage
is now ~71%.
Let the framework wire up logging through the normal app lifecycle
instead of calling LogProvider.register() by hand. The module captures
and restores the global app singleton and the root logger handlers so
booting does not leak into other test modules.

@bedus-creation bedus-creation left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review — APPROVE (posted as comment; GitHub blocks self-approval on own PR)

Verified locally (from fastapi_startkit/):

  • tests/logging/test_logging.py: 50 passed
  • Full suite (--ignore=tests/masoniteorm/postgres): 1648 passed, 7 skipped, total coverage 71.18% — clears the new fail_under = 68 with ~3.2% margin
  • Logging module coverage: 0% → 85%

Strengths:

  • Clean state hygiene: setUpModule/tearDownModule save and restore root-logger handlers, level, and the global app singleton; Logger.instance reset; tempfiles cleaned up; propagate=False on the single/syslog logger to avoid cross-talk with the installed handler.
  • Real behavior exercised, not just imports — factory resolution, level-severity filtering, channel delegation, driver output (stdout/file), Slack (mocked HTTP) and syslog (mocked handler), provider register/boot including the no-default-channel early return.
  • No production code changed apart from the fail_under bump.

No blocking issues. Recommended: merge.

…f-reference

The Slack post test compared the posted URL to driver.slack_url — the
same attribute that produced the call — so a wrong endpoint would pass.
Assert the literal endpoint and the token/channel/username payload
contract instead. Verified via mutation testing: corrupting slack_url
now fails the test.
…mezone

Fix a fixed instant on a day boundary and show two timezones produce two
differently-dated daily log files on disk, driven by
logging.channels.timezone. Verified via mutation testing: hardcoding UTC
in BaseChannel.get_time (filename) and BaseDriver.get_time (get_time)
each fails its corresponding assertion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant