What
wads.repo_audit flags replize as having no test files. That is accurate in
practice, not just formally:
-
there is no tests/ directory and no in-package tests/;
-
the only doctest in the package (replize/__init__.py) is
>>> from replize import replize
>>> replize("ls") # doctest: +SKIP
The second line is skipped (it would block on input() forever), so CI's
pytest --doctest-modules verifies exactly one thing: that the package
imports.
So replize() itself — prompt formatting, exit-command handling,
subprocess dispatch, stdout/stderr callbacks, exit_exceptions handling — has
zero automated coverage, and _replize_cli (the replize console script,
the package's main user-facing surface) has none either.
Why it matters
The function is small but has several branches that are easy to regress
silently, and it is exposed as an installed console script. A packaging or
Python-version change could break the CLI without CI noticing.
Suggested fix
The design is already test-friendly — replize() takes stdout_callback /
stderr_callback as injectable arguments, and reads input through input().
A tests/test_replize.py could:
- monkeypatch
builtins.input with a scripted sequence of lines
(e.g. ["-l", "exit"]) and collect output through capture callbacks, then
assert on what the callbacks received and that the loop terminated;
- assert that an exit command in
exit_commands breaks the loop, and that an
exception listed in exit_exceptions (e.g. EOFError raised by the patched
input) also breaks it rather than propagating;
- assert the prompt string is rendered from
prompt_template;
- cover
_replize_cli argument parsing by patching replize and calling the
entry point with a crafted sys.argv.
Using a portable command (python -c ... rather than ls) keeps it green on
the Windows leg of CI.
Notes
Raised while migrating this repo to pyproject.toml + the wads uv CI stub; the
migration pass deliberately did not add tests. Related config detail: CI
collection is driven by testpaths, now ["replize"]. If a top-level tests/
directory is added, extend testpaths to ["replize", "tests"] or the new
tests will not be collected by CI.
What
wads.repo_auditflagsreplizeas having no test files. That is accurate inpractice, not just formally:
there is no
tests/directory and no in-packagetests/;the only doctest in the package (
replize/__init__.py) isThe second line is skipped (it would block on
input()forever), so CI'spytest --doctest-modulesverifies exactly one thing: that the packageimports.
So
replize()itself — prompt formatting, exit-command handling,subprocess dispatch, stdout/stderr callbacks,
exit_exceptionshandling — haszero automated coverage, and
_replize_cli(thereplizeconsole script,the package's main user-facing surface) has none either.
Why it matters
The function is small but has several branches that are easy to regress
silently, and it is exposed as an installed console script. A packaging or
Python-version change could break the CLI without CI noticing.
Suggested fix
The design is already test-friendly —
replize()takesstdout_callback/stderr_callbackas injectable arguments, and reads input throughinput().A
tests/test_replize.pycould:builtins.inputwith a scripted sequence of lines(e.g.
["-l", "exit"]) and collect output through capture callbacks, thenassert on what the callbacks received and that the loop terminated;
exit_commandsbreaks the loop, and that anexception listed in
exit_exceptions(e.g.EOFErrorraised by the patchedinput) also breaks it rather than propagating;prompt_template;_replize_cliargument parsing by patchingreplizeand calling theentry point with a crafted
sys.argv.Using a portable command (
python -c ...rather thanls) keeps it green onthe Windows leg of CI.
Notes
Raised while migrating this repo to
pyproject.toml+ the wads uv CI stub; themigration pass deliberately did not add tests. Related config detail: CI
collection is driven by
testpaths, now["replize"]. If a top-leveltests/directory is added, extend
testpathsto["replize", "tests"]or the newtests will not be collected by CI.