Repository navigation
Write unit tests for pdb module #73784
Description
| BPO | 29598 |
|---|---|
| Nosy | @methane, @xdegaye, @serhiy-storchaka, @micgeronimo, @isidentical |
| PRs |
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 = None
closed_at = None
created_at = <Date 2017-02-19.09:49:40.599>
labels = ['3.7', 'tests']
title = 'Write unit tests for pdb module'
updated_at = <Date 2019-11-30.16:37:13.325>
user = 'https://github.com/micgeronimo'bugs.python.org fields:
activity = <Date 2019-11-30.16:37:13.325>
actor = 'BTaskaya'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2017-02-19.09:49:40.599>
creator = 'Artem Muterko'
dependencies = []
files = []
hgrepos = []
issue_num = 29598
keywords = []
message_count = 6.0
messages = ['288123', '288126', '288349', '288459', '288593', '357659']
nosy_count = 5.0
nosy_names = ['methane', 'xdegaye', 'serhiy.storchaka', 'Artem Muterko', 'BTaskaya']
pr_nums = ['218']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue29598'
versions = ['Python 3.7']
Activity
micgeronimo commentedon Feb 19, 2017
I want to write unit tests for pdb module of stdlib. Should I create one pull request for entire module or should I split work into several pull requests?
xdegaye commentedon Feb 19, 2017
Please use one single PR only when the tests are focused on a single topic and can be collected in their own class. When the tests are focused on breakpoints for example.
serhiy-storchaka commentedon Feb 22, 2017
It would be better to move all tests for internal functions in separate TestCase class. It should be clear that this is testing of implementation details and we are free to change tests when change the implementation.
There are some tests for find_function(). They should be moved too. Note that there is a bug in find_function() (it opens a file with default encoding).
Tests for internal functions don't free us from testing the same functionality as a part of high level functions.
xdegaye commentedon Feb 23, 2017
Please open an issue.
serhiy-storchaka commentedon Feb 26, 2017
And decorate this test class with test.support.cpython_only.
isidentical commentedon Nov 30, 2019
PR 218 is closed and this issue looks like just created for that PR. If that PR is closed and there are nothing to do with this issue, maybe this can also be closed?