Responses (without yet testing the code):

1. Generally, the only new subclass needed is for the master frame.  Existing Toplevel derivatives may have a single frame in the toplevel, which should become an instance of a new subclass, in this case TextviewFrame.  Some Toplevels contain multiple widgets, which will need to be moved into a new master frame.  The idea is that a single master frame can easily be put elsewhere.  For testing, it can go into the test root window.  For future IDLE, master frames might go on notebook tabs.

So we don't need the new ButtonFrame class.  I suspect that we do not even need the current button frame containing just one button.  But removing that can be deferred.

2. http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html is a good reference for 8.5, with only a few errors I have seen.  The ttk widgets are listed from 28 on.  Notebooks are for the future.

3. Yes, but the following should be moved into TextviewFrame.
         # TODO: get fg/bg from theme.
         self.bg = '#ffffff'
         self.fg = '#000000'

4. 'Containing widget', rather than 'calling class'.  ButtonFrame should go away.

5. My main objection to super(), that the abbreviated form does not work in 2.x, does not matter now that I have mostly stopped backporting to 2.7. 

6&7. I prefer the newer, more Pythonic, subscript access and, as I said before, string literals. There main issue is making isolated changes in untested code versus doing the same in well-tested code as part of refactoring and line-by-line examination.

8. I generally prefer .format to %.  For 3.6+, we now have the option of f-strings.  The expressions for x and especially y are a bit too long to directly include, but temp vars solve that. 

+        x = parent.winfo_rootx() + 10,
+        y = parent.winfo_rooty() + (10 if not _htest else 100)))
+        self.geometry("=750x500+{x}+{y}")

9. Grid is newer than pack, and at least some tk experts recommend using it in preference to pack.  (The reference above only covers gridding.  However, change is not necessary for the first refactoring.

Are you aware that running gui code files runs a visual sanity check that brings up an instance of the window?  One can quickly check the effects of changing gui code.

10. Synonyms are a nuisance, especially if one forgets that they are synonyms.  I would prefer to consistently use the attribute names without the 'wm_' prefix.  I will try to remember to fix help.py when editing it next.