Repository navigation
Assertion capture #291
Description
Part of #277
No assertion rows are captured. The JS side patches node:assert
through core/assert-patcher and renders passing and failing rows; a pytest
assertion is a rewritten assert statement, so the mechanism has to differ.
Acceptance criteria
Failing and passing assertions appear as rows carrying
expected and actual. The Errors tab collects the failures.
Activity
vishnuv688 commentedon Aug 17, 2026
Scope note: plain scripts have no interception point
This issue is written around pytest, whose assertion rewriting is what makes interception possible. A plain script has no equivalent hook:
assertis a bare language statement, and the adapter instrumentsWebDriver.execute, so anassertnever touches the driver and cannot be observed at all.Reproduced on the new login example (
examples/selenium/python-test/login.py) with a deliberately broken assertion. Neither passing nor failing assertions produce a row, and nothing in the current acceptance criteria would change that for this style of run.So the acceptance criteria need to say which of these is in scope:
pytest_assertrepr_compareor the plugin's own reporting) and attach rows to the running test. This is what the issue assumes today.devtools.expect(...)) or an explicit statement that plain scripts are out of scope.Worth resolving before implementation, because the two need different mechanisms and the plain-script path is the one the example in the docs uses.
Related but distinct, and currently untracked
The same run surfaced a separate defect that this issue would not fix:
_send_default_suiteis called with a hardcoded"passed"(packages/selenium-devtools-py/src/selenium_devtools/instrumentation.py:356) and the adapter has no failure path, so a plain-script run that raises still reports a green 1/1. The command stream stops at the failing line while the test tree claims a pass. Independent of assertion capture and needs its own issue.