gh-79871: IDLE - Fix and test debugger module

[tonybaloney]

This pull request adds tests for the (currently untested) idlelib.debugger.Idb class.

These tests are unit tests to validate the existing behaviours.

2 behaviours have been changed:

• 525efbc#diff-6428b52d9491cd87d1aaac56558bdd7bR17 changes Idb to call super (the Python 2/3 style) instead of calling __init__ directly. This won't have execution, but I think this code was written well before super existed. 17 years ago according to blame.
• 525efbc#diff-6428b52d9491cd87d1aaac56558bdd7bR49 .in_rpc_code guards against the previous frame being None. Since this method recursively checks f_back when the file matches certain conditions, if it eventually hits the first frame, f_back would be None.

• Issue: IDLE: Fix and test debugger. #79871

[tonybaloney]

Also requesting review from @csabella

[tonybaloney]

I'm going to continue merging tests into this PR instead of opening separate ones

[tonybaloney]

just realised I've been writing these all as pytest assertions. Will amend existing commits

[tonybaloney]

@terryjreedy I'm still adding tests so this isn't ready for review yet. But early feedback would be welcome as this is my first foray into the idle_test suite

[terryjreedy]

Yes, additional debugger tests should go here.

[tonybaloney]

@terryjreedy I've finished the test suite. There is quite a heavy use of mock, but mostly to isolate the behaviours and validate that the methods call the underlying components with the correct values.

I've also created a class in here as a reflection of types.FrameType which is used many times, as well as a small piece of code, which is compiled.
This is to create a frame and a code object, to simulate as much as possible (without popping up a subinterpreter) the debugging process.

Something I saw a lot but wasn't sure why it existed, where these empty single-line comments. https://github.com/python/cpython/pull/11451/files#diff-6428b52d9491cd87d1aaac56558bdd7bL235 do you know what they're for? I assumed to break up the large functions, but empty lines are normally used for that. I've never come across it before and wondered if there was a reason.

[tonybaloney]

Which commands were you using to run the tests?

From this branch, I'm running

PYTHON_PATH=Lib ./python.exe -m idlelib.idle_test.test_debugger

I ran python -m test -v -ugui test_idle but I didn't see any of these tests being run

[tonybaloney]

The 0df2512 changeset introduces an issue where the stack viewer window stays open when the tests are run. This is causing the crash on CI

[tonybaloney]

@tonybaloney, I added some inline comments mostly regarding code structure. I haven't looked in detail yet at what the tests are doing, but to answer your previous questions about further changes, I anticipate there will be more iterations of code review and changes. Just as an FYI, CPython needs to be more careful and detailed about code reviews than other projects do, so the process of having a pull request merged may take longer than you've experienced in the past.

I'm not in any rush, I want to get this right. It'll take me a bit of time to understand the feedback too as I'm unfamiliar with the process and the library

[csabella]

For running all the IDLE tests, you can just try python -m test.test_idle, instead of adding the test_debugger at the end.

One thing that I've found helpful (on both Linux and Windows) is to create a venv. On Windows (your command shows .\python.exe, so I think you're using Windows), there is a command py to run Python. Outside of the venv, it runs the system installed version, but inside the venv, it runs the version that the venv was created with. So, if you create it from your clone, then it makes working on the code a little easier, IMHO.

I'm not in any rush, I want to get this right. It'll take me a bit of time to understand the feedback too as I'm unfamiliar with the process and the library

Yeah, every project is a little different, so that's why I wanted to give you a heads up. :-)

[csabella]

The 0df2512 changeset introduces an issue where the stack viewer window stays open when the tests are run. This is causing the crash on CI

I'm not sure if teardowns will fix this or not, but they might. So, for now, I'll wait to look at the test errors and failures until then. On my machine, I'm getting these results when running the tests. Since they worked before, my first thought is that the difference would be related to changing where the objects are created, so that is what needs to be tracked down.

======================================================================
ERROR: test_interaction_with_message_and_frame (__main__.DebuggerTest)
Test the interaction sets the window message.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/idlelib/idle_test/test_debugger.py", line 207, in test_interaction_with_message_and_frame
    self.debugger.interaction(test_message, test_frame)
  File "N:\projects\cpython\lib\idlelib\debugger.py", line 284, in interaction
    b.configure(state="disabled")
  File "N:\projects\cpython\lib\tkinter\__init__.py", line 1637, in configure
    return self._configure('configure', cnf, kw)
  File "N:\projects\cpython\lib\tkinter\__init__.py", line 1627, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: invalid command name ".!listedtoplevel6.!frame.!button"

======================================================================
ERROR: test_interaction_with_message_and_frame_and_exc_info (__main__.DebuggerTest)
Test the interaction sets the window message with exception info.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/idlelib/idle_test/test_debugger.py", line 224, in test_interaction_with_message_and_frame_and_exc_info
    self.debugger.interaction(test_message, test_frame, test_exc_info)
  File "N:\projects\cpython\lib\idlelib\debugger.py", line 284, in interaction
    b.configure(state="disabled")
  File "N:\projects\cpython\lib\tkinter\__init__.py", line 1637, in configure
    return self._configure('configure', cnf, kw)
  File "N:\projects\cpython\lib\tkinter\__init__.py", line 1627, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: invalid command name ".!listedtoplevel7.!frame.!button"

======================================================================
FAIL: test_load_stack (__main__.StackViewerTest)
Test the .load_stack() method against a fixed test stack.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/idlelib/idle_test/test_debugger.py", line 388, in test_load_stack
    self.assertEqual(self.sv.get(0), '?.<module>(), line 1: ')
AssertionError: '?.<module>(), line 1: "Test stackviewer, coverage 63%."' != '?.<module>(), line 1: '
- ?.<module>(), line 1: "Test stackviewer, coverage 63%."
+ ?.<module>(), line 1:

[terryjreedy]

I run tests either from an editor window or in the console in the top repository directory. The repository has python.bat for Windows, so '3x> python -m test.test_idle' runs the tests with the latest repository build.

I re-downloaded and re-ran test_debugger both by itself and with the idle suite. The previous errors are gone. The debug controls stack up until the test pauses. It finished after I closed some. There should be only one open at a time. I get the same 2 'invalid command name' errors, but not the load_stack error. Coverage is 75% for me.

I am puzzled why the configure call fails. When I commented out b.configure(state="disabled"), the following self.status.configure(text="") apparently executed while the subsequent self.error.configure(text="", background=self.errorbg) failed.

[terryjreedy]

I should have mentioned before that I want opening comments (when appropriate) instead of docstrings for test_xyz methods. Both are equally visible to readers, but docstrings are added to the output in -v mode, which to me is a nuisance. I intend to change them, though not at the moment.

[terryjreedy]

I wondered if the fact that debug window still uses tk widgets inside a ttk Frame could be an issue (we must finish this). But I don't see any problem when using the debugger, and I am pretty sure that iteract() is being called.

[tonybaloney]

I figured out why it hangs, the .interact called self.root.tk.call('vwait', '::idledebugwait') inside the debugger module and waits for a button to be pressed. Those 2 tests need to be written in a different way.

[tonybaloney]

@csabella @terryjreedy sorry for the delay, I've refactored the code based on your comments and feedback and fixed the hanging test issues

[terryjreedy]

No problem. We have both been busy with other issues. I will look at this after doing more on tests for another IDLE module.

[tonybaloney]

@terryjreedy @csabella please could you take another look at this PR for targeting 3.9?

[arhadthedev]

Is the PR still relevant?

cc @terryjreedy, @csabella

[terryjreedy]

Probably. I plan to review all idlelib issues this summer.