Getting a strange error when decorator isn't used
alanjackman opened this issue · 3 comments
Using this syntax:
assert_that(ixn_service.get_user_preferences(VALID_CMIS_ID).json().get('offlineVoicemailNotification'), False,
f"User preference didn't match Expected")
Instead of this syntax:
assert_that(some_service.get_user_preferences(VALID_CMIS_ID).json().get('offlineVoicemailNotification'), is_(False),
f"User preference didn't match Expected")
gives me this error:
Unable to display children:Error resolving variables Traceback (most recent call last):
File "C:\Users\Some Guy\Envs\ssp\lib\site-packages\behave\model.py", line 1329, in run
match.run(runner.context)
File "C:\Users\Some Guy\Envs\ssp\lib\site-packages\behave\matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features\steps\offline_notification_preferences_steps.py", line 328, in step_impl
f"User preference didn't match Expected")
File "C:\Users\Some Guy\Envs\ssp\lib\site-packages\hamcrest\core\assert_that.py", line 45, in assert_that
_assert_bool(assertion=arg1, reason=arg2)
File "C:\Users\Some Guy\Envs\ssp\lib\site-packages\hamcrest\core\assert_that.py", line 64, in _assert_bool
raise AssertionError(reason)
AssertionError: Assertion failed
assert_that() has two forms - assert_that(actual, matcher, [reason]) and assert_that(assertion, [reason]). The call you're making isn't of the 1st form, because the 2nd argument isn't a matcher, so it's falling back to the 2nd form.
As of 2.0, which we hope to release soon, type hints would warn you that you weren't calling assert_that() properly. Other than that, I'm not sure there's much better we can do about this.