Trigger events via standard callbacks in widget testing. #29993
Conversation
| @@ -137,7 +135,7 @@ def test_rectangle_drag(ax, drag_from_anywhere, new_center): | |||
| tool = widgets.RectangleSelector(ax, interactive=True, | |||
| drag_from_anywhere=drag_from_anywhere) | |||
| # Create rectangle | |||
| click_and_drag(tool, start=(0, 10), end=(100, 120)) | |||
| click_and_drag(tool, start=(10, 10), end=(90, 120)) | |||
There was a problem hiding this comment.
The positions in the last part of this test are also outside both before and after rectangles, so just checking if those are still valid, or are they actually outside the Axes just as these were (and thus not checking what was intended)?
There was a problem hiding this comment.
The axes default to ranging from 0 to 200, so the last part's rectangles are within the axes.
|
👍 to removing |
|
The problem is that right now do_event takes a (not-standardized) widget method name as parameter. I guess, sure, we could completely change the signature and have a private |
I'm +/-0 here.
OTOH I don't have a good API either. |
Sending actual events through the whole event processing pipeline is a
more complete test, reveals a few minor issues (see changes below), and
avoids being linked to the rather nonstandard widget method names
("press" or "_click"?).
The coordinates in the "move first vertex after completing the polygon"
subtest of test_polygon_selector(draw_bounding_box=True) were altered
because the original coordinates would actually not work in a real case,
as the mouse-drag would actually also trigger the polygon-rescaling
behavior.
The coordinates in test_rectangle_{drag,resize} were altered because for
the original coordinates, the click_and_drag would actually be ignore()d
due to starting (just) outside of the axes.
Sure, we could require the caller to also pass ax.figure.canvas when using data coordinates (in which case xy could just be given as
That point I do feel quite strongly about: directly calling the event handlers, like do_event did, actually abstracted too much, as shown by the changes I had to make to the tests; going via manual event emission is the proper way to simulate what really happens, and does catch additional relevant issues. |
Sending actual events through the whole event processing pipeline is a more complete test, reveals a few minor issues (see changes below), and avoids being linked to the rather nonstandard widget method names ("press" or "_click"?).
The coordinates in the "move first vertex after completing the polygon" subtest of test_polygon_selector(draw_bounding_box=True) were altered because the original coordinates would actually not work in a real case, as the mouse-drag would actually also trigger the polygon-rescaling behavior.
The coordinates in test_rectangle_{drag,resize} were altered because for the original coordinates, the click_and_drag would actually be ignore()d due to starting (just) outside of the axes.
Closes #22720.
PR summary
PR checklist