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

[Todd V. Rovito]

On Jun 13, 2013, at 1:32 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> 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.)
This email is very helpful, thanks for taking the time to write it.

> 
> 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.
I looked at issue 18130 closely and it mostly makes sense to me but I was surprised you didn't use unittest.mock in mock_tk.  Does that mean I can assume for other unit tests that we shouldn't use unittest.mock and monkey patching without mock is ok? Using mock in the past seems like it would give us more options than monkey patching.    

Thanks!