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 bpo-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 bpo-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 bpo-30779. The testing logic should not be, however.

PR to fix type in moduleTearDown.

New changeset 25a4206 by terryjreedy in branch 'master':
bpo-30780: Fix error in idlelib.test_idle.test_configdialog (bpo-2606)
25a4206

I posted PR 2612 for bpo-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 bpo-30779. I want to move forward on this, but not duplicate your work, so please post work done and immediate plans.

New changeset df0f993 by terryjreedy in branch '3.6':
[3.6] bpo-30780: Fix error in idlelib.test_idle.test_configdialog (GH-2606) (bpo-2613)
df0f993

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

bpo-31001 and bpo-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, bpo-30617 and PR-3238, bpo-30781 are merged cross-references.
PR-3222 was closed in favor of PR-3220, bpo-31287, merged.

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

Dependency bpo-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.

New changeset dd023ad by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-30780: Add IDLE configdialog tests (bpo-3592)
dd023ad

New changeset 5aefee6 by Miss Islington (bot) in branch '3.7':
bpo-30780: Add IDLE configdialog tests (GH-3592)
5aefee6

New changeset 7b57b15 by Miss Islington (bot) in branch '3.8':
bpo-30780: Add IDLE configdialog tests (GH-3592)
7b57b15