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 unittests: make gui, mock switching easier. #65846
Comments
Idle unittests that use tkinter.Text are developed using the gui widget and then switched, to the current extent possible, to mock_tk.Text. I have done this previously by commenting out gui lines and adding new lines, so it would be possible to switch back if needed. test_searchengine is an example. However, switching back would require commenting and uncommenting several lines. When reviewing test_autoexpand bpo-18292, I realized that everything after the imports from tkinter import Text
from idlelib.idle_text.mock_tk import Text can be made conditional on 'tkinter in str(Text)'. The only comment switching needed is for the import lines. This issue is about retrofitting test_searchengine and any other files that need it. |
Perhaps, we can move GUI/non GUI code into blocks. I will take Text as example. from test import support
if support._is_gui_available():
from tkinter import Text
else:
from idlelib.idle_test.mock_tk import Text
.
.
.
if not support._is_gui_available():
parts of test which can be run keeping in mind mock.Text's limitations.
else:
everything, using tkinter.Text Only drawback is _is_gui_available is not documented publicly. Also, we'd will have lot of if...else blocks all over the place. Avoiding code duplication will be tricky. |
Tests that need at most tkinter Variables and message boxes run without gui since those are easy to mock and we want to set and retrieve values on MBox. Tests of displayed widgets other than Text are gui tests (unless we were to developed a substantial tk mock, which is beyond current plans). So the present issue is limited to test functions that involve Text and nothing else visible. Having tried it, I prefer if-(and sometimes)-else blocks to commented out code. I dislike the latter in idle files: did someone just forget to remove it? If not, why is it there? So I think your idea of completely switching to conditional code is a good idea. We must not directly switch on _is_gui_available(). If a system running tests under test, which means under test.regrtest, does not request 'gui', the gui tests should not run even if they could be. Try "python -m test -v test_idle" and you will see (at the moment) 67 OK and many skips, versus 110 ok and no skips with 'python -m test.text_idle'. I think this should work: import unicode
from test.support import requires
try:
requires('gui')
from tkinter import Tk, Text
running_gui = True
except unicode.SkipTest:
from idlelib.idle_test.mock_tk import Text
running_gui = False running_gui would then be used for conditional expressions. I believe we could wrap the above, modified, in a function, such as mock_tk.get_text. def get_text(gui_ok=True):
if gui_ok:
import unicode
from test.support import requires
try:
requires('gui')
from tkinter import Text
return Text, True
except unicode.SkipTest:
pass
# else gui not ok or not available
return Text, False and use it as follows in a test_file. from idlelib.idle_test.mock_tk import get_text # and anything else
Text, running_gui = get_text() # (0), temporarily, to force non-gui This needs to be tested. Tests would be committed without 0, though forgetting to remove it would not be tragic. Running a non-gui test on all buildbots is considered better than a gui test on a few. After thinking about your idea, I believe gui when possible, non-gui otherwise is even better. Should get_text work, but it be decided that all non-gui is better, the sense of the get_text parameter could be flipped to change all tests at once. |
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: