Skip to content
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.

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

reconsider how to assert that expectations are used #8

Open
2bndy5 opened this issue Aug 7, 2024 · 1 comment
Open

reconsider how to assert that expectations are used #8

2bndy5 opened this issue Aug 7, 2024 · 1 comment

Comments

@2bndy5
Copy link
Owner

2bndy5 commented Aug 7, 2024

Currently, the expectations are checked that they are all used upon destruction of the mocked object. However, pytest will ignore any exception thrown by a destructor. This leaves a traceback in the pytest output about "Ignored exception" when some exceptions were not used.

Possible solutions

  1. let unused expectations go unchecked

    pros cons
    The done() method can be called from the test code This may cause a deviation from expected behavior
  2. assert that done() is called upon destruction

    pros cons
    This serves as reminder to update the test code This seems to have poor behavior with the monkey_patch_sys_paths fixture because it is set to autouse=True (see also move pytest fixture into submodule #9 )

Additional context

Because pytest manages setup and tear-down as an internal implementation detail, this is destructor approach is rather undesirable.

@2bndy5 2bndy5 changed the title reconsider asserting expectations are used reconsider asserting how expectations are used Aug 7, 2024
@2bndy5 2bndy5 changed the title reconsider asserting how expectations are used reconsider how to assert that expectations are used Aug 7, 2024
@2bndy5
Copy link
Owner Author

2bndy5 commented Aug 9, 2024

I'm inclined to go with option 1 because tests could expectedly fail (pytest.marks.xfail). Relying on a mock's destructor would force users' test code to overcompensate for a mock's behavior that asserts all expectations are used. It would be better to let a mock's done() be optionally invoked when appropriate.

As this library is largely influenced by embedded-hal-mock (for rust), going with option 1 is a serious deviation from that lib's design.

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

No branches or pull requests

1 participant