Eventually matcher can't handle the Raises matcher
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Autopilot |
Fix Released
|
High
|
Unassigned | ||
autopilot (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
When we use Eventually in combination with the Raises matcher, the exception thrown is not caught.
>>> from autopilot.matchers import Eventually
>>> from testtools.matchers import raises
>>> matcher = Eventually(
>>> def bad_fn():
... raise RuntimeError(
...
>>> bad_fn()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in bad_fn
RuntimeError: Hello
>>> matcher.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/
wait_
File "/usr/lib/
new_value = refresh_fn()
File "<stdin>", line 2, in bad_fn
RuntimeError: Hello
Related branches
- Leo Arias (community): Approve
- Christopher Lee (community): Approve
- PS Jenkins bot: Approve (continuous-integration)
-
Diff: 22 lines (+4/-1)1 file modifiedautopilot/matchers/__init__.py (+4/-1)
Changed in autopilot: | |
assignee: | nobody → Thomi Richards (thomir) |
status: | Triaged → In Progress |
Changed in autopilot: | |
status: | In Progress → Fix Released |
This is a bug in autopilot. The root problem is that we allow people to pass in a callable method to assertThat, like so:
self.assertThat (lambda: self.get_thing(1, 2, 3), Eventually( Equals( 'something' )))
The Eventually matcher breaks the behavior defined in testtools - it calls the matchee when it should instead pass it to the underlying matcher.
I think we need to figure out how to fix this. Off the top of my head, there's no easy solution. Need to think about this some more. Suggestions welcome;