Issue 18910: IDle: test textView.py

Started writing the tests for textView.py.

New changeset 9ac57970ee4c by Terry Jan Reedy in branch '2.7':
Issue #18910: Add unittest for textView. Patch by Phil Webster.
http://hg.python.org/cpython/rev/9ac57970ee4c

New changeset 99047f3a19a9 by Terry Jan Reedy in branch '3.4':
Issue #18910: Add unittest for textView. Patch by Phil Webster.
http://hg.python.org/cpython/rev/99047f3a19a9

The use of .__new__ was cute. Unfortunately, it did not backport to 2.7 because tkinter classes were never upgraded from old to new in 2.7 and old-style classes do not have .__new__. So I monkeypatched the module instead, which is a but clumbsier than patching the instance.
Though not every detail is tested, coverage is essentialy 100% and the human text covers the visual details.

Since all tests create a widget with widgets (or destroy it), the new patch moves root to class scope and simplifies the code a bit. It also subclasses TextViewer instead of monkey-patching it. Modules have to be monkey-patched because they cannot be 'sub-moduled'.

New changeset 86ba41b7bb46 by Terry Jan Reedy in branch '2.7':
Issue #18910: test_textView - since all tests require 'gui', make root global.
http://hg.python.org/cpython/rev/86ba41b7bb46

New changeset 5a46ebfa5d90 by Terry Jan Reedy in branch '3.4':
Issue #18910: test_textView - since all tests require 'gui', make root global.
http://hg.python.org/cpython/rev/5a46ebfa5d90

It looks like the 2.7 checkin has caused a number of buildbots to fail.  Examples:

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%202.7/builds/1094/steps/test/logs/stdio

======================================================================
ERROR: idlelib.idle_test.test_textview (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: idlelib.idle_test.test_textview
Traceback (most recent call last):
  File "/opt/python/2.7.langa-ubuntu/build/Lib/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/opt/python/2.7.langa-ubuntu/build/Lib/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "/opt/python/2.7.langa-ubuntu/build/Lib/idlelib/idle_test/test_textview.py", line 11, in <module>
    requires('gui')
  File "/opt/python/2.7.langa-ubuntu/build/Lib/test/test_support.py", line 359, in requires
    raise ResourceDenied(_is_gui_available.reason)
ResourceDenied: Tk unavailable due to TclError: no display name and no $DISPLAY environment variab [...]

and:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%202.7/builds/440/steps/test/logs/stdio

======================================================================
ERROR: idlelib.idle_test.test_textview (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
ImportError: Failed to import test module: idlelib.idle_test.test_textview
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/2.7.murray-snowleopard/build/Lib/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/Users/buildbot/buildarea/2.7.murray-snowleopard/build/Lib/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "/Users/buildbot/buildarea/2.7.murray-snowleopard/build/Lib/idlelib/idle_test/test_textview.py", line 11, in <module>
    requires('gui')
  File "/Users/buildbot/buildarea/2.7.murray-snowleopard/build/Lib/test/test_support.py", line 359, in requires
    raise ResourceDenied(_is_gui_available.reason)
ResourceDenied: gui tests cannot run without OS X window manager

Please don't create Tk object at module creating stage. I afraid this will break unittest discoverity.

The 3.4 stable buildbots are green except for two that ran test_idle ok.
The problem is that in 2.7, unittest.loader does not catch ResourceDenied at module level whereas is does in 3.4. The only indication that there should be a difference is that the 3.x doc has "Skipped modules will not have setUpModule() or tearDownModule() run."

I am puzzled though, since the manual says this was added in 3.1 and 2.7 came out after. Also, I presume that 2.7 test.regrtest honors the SkipTest raised by 2.7 test_support.import_module, which is usually used at module level. 

If someone wants to revert the patch, go ahead. I have to get some sleep before I do anything (it is 5 am).
--

"Please don't create Tk object at module creating stage."
I didn't. I intentionally put TK stuff inside setUpModule so it would happen at test running stage.

New changeset a0be81607a50 by Benjamin Peterson in branch '2.7':
backed out 86ba41b7bb46 (#18910) for test breakage
http://hg.python.org/cpython/rev/a0be81607a50

The changeset Benjamin backed out is pretty much fine, just needs the requires('gui') to be at the top of setUpModule instead of at toplevel.  That does mean the whole module is constructed and then thrown away without doing anything, but it at least runs properly even with no Tk available.

Yes, early skipping was the reason I put the test where I did. The simple change occurred to me today. I have not decided yet whether to also change the 3.4/5 files to match and how to edit the testing README. For one test, I would not care either way. But I expect there to be more files with the same issue, So I wonder what is the best way to avoid hitting the same booby trap again.

New changeset f5e20abea871 by Terry Jan Reedy in branch '2.7':
Issue 18910: Edit idle_test/README.txt to add 'requires' warning.
https://hg.python.org/cpython/rev/f5e20abea871

New changeset 735eebce6765 by Terry Jan Reedy in branch '3.5':
Issue 18910: Edit idle_test/README.txt to add 'requires' usage at module scope.
https://hg.python.org/cpython/rev/735eebce6765

I have stopped patching IDLE for 2.7 and will not add more tests.  So there is no reason to constrain tests for 3.5, and soon 3.6, to 2.7 limitations.

assignee: terry.reedy
resolution: fixed
stage: needs patch -> resolved

nosy: + ned.deily
messages: + msg219921

resolution: fixed -> (no value)
stage: resolved -> needs patch

resolution: fixed
stage: patch review -> resolved