Skip to content

CHIA-2090 Add a section about monkey-patching in tests to PRETTY_GOOD_PRACTICES.md #19053

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

CHIA-2090 Add a section about monkey-patching in tests to PRETTY_GOOD_PRACTICES.md #19053

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions PRETTY_GOOD_PRACTICES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -619,6 +619,9 @@ class SomeWallet:
pytest does not.
Our tests are fully dependent on pytest so there's no use in retaining `unittest` compatibility for this single point.
Making a few tests `unittest` compatible is not useful compared with the cost of inconsistency.
- Avoid monkey-patching (assigning to a method on a class object or instance) as much as possible.
If necessary, opt for it in an explicit and scoped manner using the `monkeypatch: pytest.MonkeyPatch` fixture with a context manager, instead of silencing mypy using `# type: ignore[assignment]`.
While in both cases we're signaling to the reader that something smelly/shady is going on, and type safety is lost, the monkeypatch approach with a context manager allows us to make the scope of the change controlled consistently.
Copy link
Contributor

@arvidn arvidn Feb 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I fail to see the benefit of using monkey patch instead of mypy suppressions.
using monkey patch is much more verbose, and risk diluting the important logic.
what kind of "scope" is more consistently controlled with monkey patch compared to a suppression?
do you mean "consistent" in the sense that the code base should only use money patch and no mypy suppressions?

Copy link
Contributor

Choose a reason for hiding this comment

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

fIrst, i didn't approve this because i wasn't quite comfortable with it, but I'll have to go back and review discussions with amine to remind myself what i had considered.

but, directly to the scope question, we certainly do have cases where we just assign to stuff and the effects just live on forever. being explicit about the scope with a context manager clarifies when the patch is intended to be removed. this certainly is less relevant when patching attributes of instances and more relevant when patching classes, modules, and functions.

(p.s. go ahead and raise a concern :])


## CLI

Expand Down
Loading