@mlouielu, thanks for your PR! By analyzing the history of the files in this pull request, we identified @terryjreedy, @csabella and @kbkaiser to be potential reviewers.

Appveyor, running on Windows, and my Win 10 machine, say:

FAIL: test_key_up_down_should_change_font_and_sample (idlelib.idle_test.test_configdialog.FontTabTest)
Traceback (most recent call last):
File "C:\projects\cpython\lib\idlelib\idle_test\test_configdialog.py", line 100, in test_key_up_down_should_change_font_and_sample
self.assertNotEqual(down_font, font)
AssertionError: 'Courier New' == 'Courier New'
EDIT
These look the same to me, so this test should fail.
print('\n', [ord(c) for c in down_font], '\n', [ord(c) for c in font])
I will try to figure out why OS should make a difference, and what is going on on Windows.

@terryjreedy I think the assertion is correct, the result we want to pass is the down_font different with font, since down_font expected be another font.

After adding focus_force, it pass both on travis and appveyor.

@mlouielu I initially mis-interpreted Appveyor result before I ran test myself and realized that the failure was correct and pointed to a need for a fix. I presume focus_force created no problem on your Linux.

I have reviewed and am revising and will push for review and test. Please don't push any more commits for now.

Changes:

1. Using verb configure for the dialog was a mistake, probably mine. Corrected.
2. Testing events and event_handler together is necessary. Trying to test set_font_sample at the same time was my mistake. I corrected this by masking the function with an instance mock that could be queried about calls. I moved these 2 tests into a new class which describes what is to be tested.
3. It does not matter what item on the list starts as active, so the first is as good as any. What matters is what happens after the simulated user actions.
4. Abbreviated 'dialog.fontlist' as 'fontlist'.
5. Setting tk font Variables has no effect on fontlist. Deleting that block had no effect.
6. The click test did not test the effect of clicking. It passed without the simulated click. The generated button press is needed to set the anchor read in the event handler. Added a test that the click actually selected the intended item.

@terryjreedy Thanks for your help, this makes the test more reliable. I fix some nit point about styling. Otherwise LGTM.