On Jun 13, 2013, at 1:32 AM, Terry Reedy <[email protected]> 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! _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
