A complete test of the GUI  will simulate user interaction with every widget and then query Changes() to see that the proper changes orders have been recorded.

This issue depends on #30779, factor out Changes class.

Tests should be tested on MacOS before being pushed.  A possible issue is including constants that are different on different systems.  See #28572

I'm trying to add the test on configdialog, currently working on KeysTest.

Proceed as you want.  Keep in mind that the interface to the changes structure will be changed by #30779.  The testing logic should not be, however.

PR to fix type in moduleTearDown.

New changeset 25a4206c243e3b1fa6f5b1c72a11b409b007694d by terryjreedy in branch 'master':
bpo-30780: Fix error in idlelib.test_idle.test_configdialog (#2606)
https://github.com/python/cpython/commit/25a4206c243e3b1fa6f5b1c72a11b409b007694d

I posted PR 2612 for #30779 and expect to merge it tomorrow after sleep and final review.  It includes passing revisions of existing configdialog tests.  A PR dependent on 2612 could be posted before I do the merge.

Follow the model of using xyzpage names in asserts and tests would survive the refactoring of ConfigChanges discussed as a possibility on #30779.  I want to move forward on this, but not duplicate your work, so please post work done and immediate plans.

New changeset df0f99329843c10701ffaefbd3948ac698c12220 by terryjreedy in branch '3.6':
[3.6] bpo-30780: Fix error in idlelib.test_idle.test_configdialog (GH-2606) (#2613)
https://github.com/python/cpython/commit/df0f99329843c10701ffaefbd3948ac698c12220

This issue is almost done.  There are just a few things missed by the closed dependencies.

#31001 and #31002 have notes on what not tested in HighPage and KeysPage.

I've started working on the missing tests for HighPage and KeysPage and also test for the functions and buttons in ConfigDialog.  That led to PR3238 because the 'help' button wasn't working.

Anyway, I found the following on http://effbot.org/tkinterbook/tkinter-events-and-bindings.htm:

"An easier solution is to prevent Tkinter from propagating the event to other handlers; just return the string “break” from your event handler:

def ignore(event):
    return "break"
text.bind("<Return>", ignore)
or

text.bind("<Return>", lambda e: "break")"

So, it seems that the 'Double-Button-1' and 'B1-Motion' bindings are to prevent those events from propagating outside of the widget.  Although, I didn't notice a difference when I commented them out, so maybe they don't have a higher level binding.

I just pushed the extension conversion patch.  The tests we did already were greatly helpful, and some tests not done or inadequate hindered.  I am now looking to polish configdialog before 3.6.3.  If you have anything worth a new issue and PR, I will be ready to review.

Sorry I don't have any tests yet.  I've added a few, but it's taking me forever to figure out the bindings for testing the `Double-Button-1` and `B1-Motion`.  I actually have a test for `Double-Button-1` now, but still working on `B1-Motion`.

I've submitted a PR for the tests that I added to complete coverage for Keys and Highlights and to add some GUI tests for the buttons.  It's not everything that I wanted to do, but it ended up being more substantial than I realized.

Here's the issue I was having with testing `Double-Button-1` and `B1-Motion`.  After the first ButtonPress and ButtonRelease, the second (or later) event-generate always looked like it was a double click (it probably was really a triple click or higher, depending how many times I tried it).  I tried everything I could think of or find online, but I couldn't find how to reset the counts to start over and make it think it was a just `ButtonPress` and not a `Double-Button`.  

This was OK for the testing on `Double-Button`, but it was causing the `B1-Motion` not to work because it was not seeing each 'movement' as a press/move/release, but rather a double-button/move/release.  It was OK because the Double also invokes the Press callback, however, since the Double event was bound to `break`, it didn't allow the text to be selected. (The difference between `Double` and `B1-Motion` is that Double selects a word and B1-Motion selects where the mouse moves).

I played with it in IDLE and I could reset the Press by doing an event-generate on a different (x, y), but that didn't work in the test.  I tried a delay and it still didn't fix it.

Anyway, I've learned a lot about mouse binding while working on this, but without a solution, I cheated and just did ButtonPress on a different (x, y) for the second test.

Sorry about the rambling, but I'd love to know the trick to resetting the number of button presses in a test.

Review of overview:
PR-2706 and PR-2613 fixed one line in test_configdialog for this issue.
PR-2046, #30617 and PR-3238, #30781 are merged cross-references.
PR-3222 was closed in favor of PR-3220, #31287, merged.

PR-3592 completes highlights and keys coverage and needs my review after getting lost in the flurry of PRs.

Dependency #31414 has merged PRs.  I should review, close, or indicate what is left to do.

Other dependencies are closed and I believe this should be after handling above 2 items.