Ezio, thank you for the response.

1. I care more about where the directory of tests is than what it is called. 'idle_test' or 'idletest' or whatever would be fine. Lets make that the last bikeshed item ;-).

2. I looked as #10572. It was originally about moving unittest tests from unittest/xx to test/yy, and then broadened to other packages. Michael F. gave two reasons for the move.

2A. Easier to grep without recursing into the test directory. Barry already refuted this, pointing out that grep/find have options to not recurse. The Idle equivalent, Find in Files, has a little checkbox
 [] Recurse down subdirectories.
I think Michael had this point backwards. The advantage of having tests with the code is to make grepping both at once possible. I am sure I will want to do this while developing the tests. So add this to my list of reasons to put the directory under idlelib.

2B. Would honor the Windows Install without Tests option. This is strictly a matter of saving space by disabling function. I agree that this is appropriate for nearly all packages, but I already explained why I want to evade that option: tkinter and idle are exceptional in that they are the only two packages that people regularly have problems running. So I think people should have those tests available, even if none of the others.

2 (again). Other people opined that package maintainers should have some say in the matter and that there might be exceptions.

3. Many modules have more or useless 'sanity-check' tests run with the 'if __name__' mechanism. I think *all* of these should be replaced with unittest.main(xxx, verbosity=2, exit=False) to run the full test module. If the code module test has anything valuable that is not in the test module, it should be moved there; the rest should be deleted.

I plan to eventually do this with all such 'tests' in idlelib/*.py. However, this needs to be done one by one. Some current tests have program errors; my 'file' to 'open' patch last week was the first fix. Some put up a blank window, with no indication of what a person is expected to do to perform the test. Some put up a window that will not close by normal means. All except the two in idletasks.diff require human intervention, which is not acceptible for buildbots. Question: is there a way for a test to detect being run by a buildbot?

4. I already used @template.txt to alter CallTips.py and start test_calltips.py and I want to use it for all the other 60 (or whatever) test files. I will (re)read the test-writing section and possibly suggest a patch. But Idle-specific info and code does not belong there.

(5.) unittest.SkipTest is what I was looking for. I do not believe that support.import_module() will allow skipping if, or unless, the test is running on a specific platform. I need to look at #16935.

Is Idle CPython only? If so, that should be a condition of test/test_idle.py running. Ah, testing the imports of tkinter and idlelib already takes care of that.

(6.) My concern and possible confusion about raising exceptions came from Jayakrishnan's patch
+    def test_DirBrowserTreeItem(self):
+        # Issue16226 - make sure that getting a sublist works
+        d = PathBrowser.DirBrowserTreeItem('')
+        d.GetSubList()
in relation to the doc saying "Note that in order to test something, we use one of the assert*() methods provided by the TestCase base class." There is no such method. The doc follows with "If the test fails, an exception will be raised, and unittest will identify the test case as a failure. Any other exceptions will be treated as errors." The 'test above is to raise, or not, an 'other exception' and I took 'treated as errors' to mean that raising an 'other exception' is an error. It certainly makes test failure counted as an error rather than an error and indistinguishable from test code errors. I guess when the test is fleshed out, there should and will be some assert about the result of d.getsublist(). So I could delete the try-except.

(7.) A human-intervention resource. I will leave that for later. 
My next step after this one is moving tests from CallTips.py to the new test_calltips.py (3. above).