What if you could instantly see only the errors in your test logs without endless scrolling?
Why Log level filtering in PyTest? - Purpose & Use Cases
Imagine running a test suite that produces hundreds of log messages. You try to find important errors by scrolling through endless info and debug messages.
Manually scanning logs is slow and tiring. You might miss critical errors hidden among less important messages. It's easy to get overwhelmed and frustrated.
Log level filtering lets you automatically show only the messages you care about, like errors or warnings. This saves time and helps you focus on real problems.
print(all logs, then search manually for 'ERROR')
pytest --log-cli-level=ERROR # shows only error logs during testsIt enables quick spotting of critical issues by filtering out noise in test logs.
When testing a web app, you only want to see error logs to fix crashes, not every info message about user clicks.
Manual log checking is slow and error-prone.
Log level filtering automatically shows important messages.
This helps testers find and fix bugs faster.
Practice
caplog.at_level() do in pytest?Solution
Step 1: Understand caplog usage
caplogis a pytest fixture used to capture log messages during tests.Step 2: Purpose of
The methodat_level()at_level()sets the minimum log level to capture, filtering out lower-level messages.Final Answer:
It sets the minimum log level to capture during a test. -> Option AQuick Check:
caplog.at_level() sets log capture level [OK]
- Thinking it clears logs instead of setting level
- Confusing it with disabling logging
- Assuming it changes log format
Solution
Step 1: Identify correct method usage
The correct method to set log level context iscaplog.at_level()used withwithstatement.Step 2: Check syntax correctness
with caplog.at_level(logging.WARNING): useswith caplog.at_level(logging.WARNING):which is the documented and correct syntax.Final Answer:
with caplog.at_level(logging.WARNING): -> Option AQuick Check:
Use with caplog.at_level(level) for filtering [OK]
- Using assignment instead of context manager
- Using non-existent methods like set_level or capture_level
- Missing the with statement
import logging
def test_logs(caplog):
with caplog.at_level(logging.ERROR):
logging.warning('Warning message')
logging.error('Error message')
return caplog.records
Solution
Step 1: Understand log level filtering
Settingcaplog.at_level(logging.ERROR)captures logs at ERROR level or higher only.Step 2: Analyze logged messages
Warning is below ERROR level, so it is ignored. Error message is at ERROR level, so it is captured.Final Answer:
Only 'Error message' is captured. -> Option CQuick Check:
ERROR level filters out WARNING [OK]
- Assuming WARNING logs appear when level is ERROR
- Thinking all logs are captured regardless of level
- Confusing ERROR and WARNING levels
def test_example(caplog):
caplog.at_level(logging.INFO)
logging.debug('Debug message')
logging.info('Info message')
assert 'Info message' in caplog.text
Solution
Step 1: Check caplog.at_level usage
The methodat_level()must be used with awithstatement to set the log level context.Step 2: Identify the error
Callingcaplog.at_level(logging.INFO)withoutwithdoes not set the level properly, so logs may not be filtered as expected.Final Answer:
caplog.at_level() must be used as a context manager with 'with'. -> Option BQuick Check:
Use 'with caplog.at_level(level):' always [OK]
- Calling at_level() without 'with' statement
- Assuming caplog.text is invalid (it exists)
- Thinking assert syntax is wrong
Solution
Step 1: Determine log levels to capture
Settingcaplog.at_level(logging.INFO)captures INFO and ERROR logs but excludes DEBUG logs.Step 2: Verify assertions
with caplog.at_level(logging.INFO): func() assert 'DEBUG message' not in caplog.text asserts DEBUG messages are not in captured logs, which matches the requirement.Final Answer:
with caplog.at_level(logging.INFO): func() assert 'DEBUG message' not in caplog.text -> Option DQuick Check:
Set level INFO to exclude DEBUG logs [OK]
- Setting level too low and capturing DEBUG logs
- Setting level too high and missing INFO logs
- Wrong assertion about presence of DEBUG logs
Ready to prove it?
Pass the test and this pattern moves unknown
