New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDle: test textView.py #63110
Comments
Started writing the tests for textView.py. |
New changeset 9ac57970ee4c by Terry Jan Reedy in branch '2.7': New changeset 99047f3a19a9 by Terry Jan Reedy in branch '3.4': |
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. |
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': New changeset 5a46ebfa5d90 by Terry Jan Reedy in branch '3.4': |
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 ====================================================================== 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 ====================================================================== 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. 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." |
New changeset a0be81607a50 by Benjamin Peterson in branch '2.7': |
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': New changeset 735eebce6765 by Terry Jan Reedy in branch '3.5': |
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: