You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test_dis should test the dis module, not everything else #90916
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2022-02-15.14:17:08.858>labels= ['type-feature', 'tests']
title='test_dis should test the dis module, not everything else'updated_at=<Date2022-02-18.21:38:39.147>user='https://github.com/markshannon'
This is getting really annoying.
It takes longer to fix all the heavily coupled and poorly written tests in test_dis than to make the real changes.
Tiny changes in the calling sequence, or reordering CFGs, cause huge diffs in the test_dis module.
No one ever checks these changes, they are just noise.
I've put this under "enhancement" as there is no "wastes a huge amount of time" category.
</rant>
The test_dis should not:
Contain offsets; they turn one line diffs into 100 line diffs.
Contain tests for the compiler; they belong elsewhere.
Contain big strings; write proper tests not just regex matches.
Tests for Instruction should should not depend on the compiler output; create the bytecode directly.
This is not a new problem, but it does seem to be getting progressively worse.
A lot of the irritation stems from b39fd0c
although the tests from before that still hardcode offsets.
With IDLE, I have issues with trying to test IDLE code without retesting tkinter, as well as deciding on the proper units of behavior to test.
Some suggestions:
Add a docstring to the module with guidelines, after review from a couple of others.
For instance,I believe you are saying that no test should explicitly call compile. Rather the test writer should call compile and extract the bytecode to copy into a test.
Make yourself a module code owner so you get informed and can review. Reviewing would be easier with guidelines to refer to, instead of repeating them.
An example issue is that some callables take many types of arguments. If not already, tests that the function can extract the bytecode from various objects should be separate from tests that extracted bytecode is then handled properly. Would any internal refactoring of dis and addition of _test functions make it easier to make test more independent of each other?
i'm interested in working on this (and refactoring dis to support better testability if needed). i like @terryjreedy 's ideas in general so i can start by implementing some of them.
I think the most complex part of this issue is to make sure that the things that are covered by test_dis (and which do not belong there) are covered by other tests. Only then we can reduce test_dis to the right scope.
Contain big strings; write proper tests not just regex matches.
do you mean that we should always be matching the structured output of _get_instruction_bytes and not the formatted string output of _disassemble_bytes?
Activity
markshannon commentedon Feb 15, 2022
<rant>
This is getting really annoying.
It takes longer to fix all the heavily coupled and poorly written tests in test_dis than to make the real changes.
Tiny changes in the calling sequence, or reordering CFGs, cause huge diffs in the test_dis module.
No one ever checks these changes, they are just noise.
I've put this under "enhancement" as there is no "wastes a huge amount of time" category.
</rant>
The test_dis should not:
This is not a new problem, but it does seem to be getting progressively worse.
A lot of the irritation stems from
b39fd0c
although the tests from before that still hardcode offsets.
terryjreedy commentedon Feb 18, 2022
With IDLE, I have issues with trying to test IDLE code without retesting tkinter, as well as deciding on the proper units of behavior to test.
Some suggestions:
Add a docstring to the module with guidelines, after review from a couple of others.
For instance,I believe you are saying that no test should explicitly call compile. Rather the test writer should call compile and extract the bytecode to copy into a test.
Make yourself a module code owner so you get informed and can review. Reviewing would be easier with guidelines to refer to, instead of repeating them.
An example issue is that some callables take many types of arguments. If not already, tests that the function can extract the bytecode from various objects should be separate from tests that extracted bytecode is then handled properly. Would any internal refactoring of dis and addition of _test functions make it easier to make test more independent of each other?
I would rather read the multiple long lists like
condensed to
martindemello commentedon Aug 31, 2022
i'm interested in working on this (and refactoring dis to support better testability if needed). i like @terryjreedy 's ideas in general so i can start by implementing some of them.
iritkatriel commentedon Aug 31, 2022
I think the most complex part of this issue is to make sure that the things that are covered by test_dis (and which do not belong there) are covered by other tests. Only then we can reduce test_dis to the right scope.
terryjreedy commentedon Sep 1, 2022
I added checkboxes to Mark's todo list in the initial post. The first item is already fixed.
martindemello commentedon Sep 1, 2022
there are still offsets in the
Instruction(...)lists; I'll get rid of them in the next PR, so that this one can remain a pure refactoring.martindemello commentedon Sep 1, 2022
by this:
do you mean that we should always be matching the structured output of
_get_instruction_bytesand not the formatted string output of_disassemble_bytes?GH-90916: Add helper function to dis.Instruction and use it to reduce…