Robust Testing of Tkinter Menu Items with Mocking. (Python recipe) by Stephen Rigden

ActiveState Code (http://code.activestate.com/recipes/578964/)

Please Note: This recipe was written while I was trying to grapple with the problems of applying TDD to tkinter. I no longer consider it good practice.

• The approach ultimately failed because of unmockable side-effects that could not be cleared in the tearDown method. (tkinter predates TDD and was not originally designed with TDD in mind)
• Test calls into tkinter were taking around 150 to 200 ms for each test unit.
• Although the tests were useful in testing that tkinter's behavior match my understanding of tkinter they looked more like integration tests than unit tests. For my current approach see test_guidialogs.py and guidialogs.py.

dialog.py is based on Fredrik Lundh's dialogs.

Original Discussion

Unittests for Tk use Tk's invoke method. The menu bar and the menu are identified by their internal name but the menu item is identified by its index.

app.children['account menubar'].children['help menu'].invoke(1)

The problem with this code is that any change to the menu sequence will break the test. Tk does offer an alternative to the index which is to use the menu item's label. Now the line will look like this:

app.children['account menubar'].children['help menu'].invoke('About Accounts')

Unfortunately, this isn't much better. The 'About Accounts' label is read in from the configuration file. It was put there so the language seen by the user could be easily changed. When the French translator changes this to its French equivalent the test will break.

This recipe solves this problem by mocking the call to ConfigParser and supplying private test labels via mock's side_effect method.

mock_get_value.side_effect = self.config

The list supplied to side_effect is built in a manner which minimizes the chance of introducing errors when menu items are rearranged. The test fixture's setUp method builds the values that will be added by AccountWindow's .__init__ method. Each item in this list matches one call to ConfigParser's get method.

def setUp(self):
    self.config = ['',  # __init__() config calls, Window title.
                   self.HELP_HELP,  # Help menu item
                   self.HELP_ABOUT,  # About menu item
                   '']  # Help menu

The final values are added by each test via the messagebox_helper mehtod. The negative indexing of self.config in the messagebox_helper method isolates this code from any future changes to self.config in setUp.

    self.config += ['title',  # app.messagebox config calls
                    'message']
    ...
    mock_messagebox.assert_called_with(self.config[-2],
                                       self.config[-1],
                                       parent=app, **kwargs)

The Tk messagebox is mocked not only because testing Tk should not be part of this program's test suite but to prevent invoke from creating the message box and its parent window on the screen. The test would halt after creating the message box waiting for user interaction.

The helper method messagebox also demonstrates the correct sequencing of regular arguments, mock.patch decorator arguments, and keyword arguments.

@unittest.mock.patch('gui.acc.configparser.ConfigParser.get')
@unittest.mock.patch('gui.acc.messagebox.showinfo')
def messagebox_helper(
        self, menu_item, mock_messagebox, mock_get_value, **kwargs):

A note on the clunky looking messageboxes:

I believe the messagebox was provided as a convenience function with Tk and it has been used here for simplicity. Tk is rightly disliked for its clunky buttons which look out of place on contemporary desktops. Newer versions of Python include the ttk extension package which allows the programmer to easily create message boxes that automatically adopt the look and feel requirements of the target platform.