[Idle-dev] Idle Testing: Recent Thoughts, mock_tk

Terry Reedy tjreedy at udel.edu
Thu Jun 13 07:32:46 CEST 2013


With other people working on Idle tests, I want to share my recent 
experience. (Some of this should go in idle_test.README.txt or another 
doc, when I have time.)

Idle tests are written with the unittest module, to be runnable with 
unittest.main. This mean no test_main() function (part of the older 
regrtest system), which is being removed from older test modules. (Over 
10 were changed in just the last day.)

Idle functions and class methods mostly focus on either creating or 
operating  gui or on non-gui calculations. This suggests gui tests for 
the first and non-gui for the latter. The problem is that non-gui 
methods can use gui-elements, which make the test a gui-using test 
unless they are replaced with mocks.

For instance, configSectionNameDialog.GetCfgSectionNameDialog.name_ok 
(altered spelling) checks user input and returns the stripped version. 
It gets the input from a StringVar and displays error messages with 
tkMessageBox.showerror. A messagebox is obvious a gui element, but so 
are Variable subclass instances, because they require a Tk master 
object. (Since Variables are not visible widgets, this surprised me).

Module mock_tk, used in test_name_dialog, has replacements for Variables 
and messageboxes. See the patch for issue 18130 or the new files in 
idle_test. Since tkMessageBox is a configSectionNameDialog global name 
(bound to a module), it is replaced in the module itself (for the 
duration of the test) by a mock messagebox, whose instances simply 
record the inputs for later examination. (This is colloquially called 
monkeypatching.) The fact that module functions and class methods can be 
accessed and called the same way means the module can be replaced by a 
class.

The StringVar accessed by name_ok is an instance attribute. So it is 
replaced by its mock in the dummy class defined in the test module. The 
dummy class provides a gui-free environment with the minimum attributes 
needed for the function to operate and be tested. Python makes this all 
easier than I expected.

I have a patch that does something similar for one of the three 
calculation methods in GrepDialog.GrepDialog. I hope to apply it soon, 
along with tests for the other two.

 From 18104: Idle: make human-mediated GUI tests usable
"23 of the 62 idlelib/*.py files have an 'if __name__ ...' test that 
brings up a tkinter gui widget and waits for the human tester to do ... 
something." The work on configSectionNameDialog started with getting its 
'test' to run and then deciding on and writing minimal instructions for 
actually testing it. That lead to automation of much of the checking. 
The residual minimum for humans is to check the visual appearance. For 
instance, the buttons were not centered until I removed the 'uncenter' 
argument.

18103: Create a GUI test framework for Idle; needs more work

-- 
Terry Jan Reedy



More information about the IDLE-dev mailing list