X Tutup
The Wayback Machine - https://web.archive.org/web/20240112020208/https://github.com/python/cpython/issues/59215
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods #59215

Open
bitdancer opened this issue Jun 6, 2012 · 5 comments
Open

unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods #59215

bitdancer opened this issue Jun 6, 2012 · 5 comments
Labels
3.11 bug and security fixes 3.12 bugs and security fixes 3.13 new features, bugs and security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@bitdancer
Copy link
Member

BPO 15010
Nosy @bitdancer, @voidspace, @ZackerySpytz
PRs
  • gh-59215: unittest: _top_level_dir is incorrectly persisted #15242
    		•
    Files
  • restore_top_level_dir.patch
  • restore_top_level_dir_to_previous_value.patch
    		•

    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 2012-06-06.01:20:42.735>
labels = ['type-bug', 'library', '3.9', '3.10', '3.11']
title = 'unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods'
updated_at = <Date 2021-11-27.11:54:46.946>
user = 'https://github.com/bitdancer'

    bugs.python.org fields:

    activity = <Date 2021-11-27.11:54:46.946>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2012-06-06.01:20:42.735>
creator = 'r.david.murray'
dependencies = []
files = ['26442', '26458']
hgrepos = []
issue_num = 15010
keywords = ['patch']
message_count = 5.0
messages = ['162387', '165887', '165954', '165966', '348649']
nosy_count = 4.0
nosy_names = ['r.david.murray', 'michael.foord', 'igorsobreira', 'ZackerySpytz']
pr_nums = ['15242']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15010'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
    @bitdancer
    Copy link
    Member Author

    During the execution of the load tests protocol, the loader instance will set its _top_level_dir attribute, and this will persist if the loader is passed on to another load_tests method. If that method does not specify a top_level_dir in a discovery call, the wrong top_level_dir may be used, and loading will fail.

    You can reproduce this by having two test *packages* with a load_tests method that calls discover in their __init__.py, and specify both package names to the unittest CLI.

    @bitdancer bitdancer added easy stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jun 6, 2012
    @igorsobreira
    Copy link
    Mannequin

    igorsobreira mannequin commented Jul 19, 2012

    Hello. I've attached a patch to cleanup self._top_level_dir in the end of discover(). Is that the expected behavior or I'm on the wrong track?

    @igorsobreira
    Copy link
    Mannequin

    igorsobreira mannequin commented Jul 20, 2012

    My previous patch is incorrect, talking to voidspace on irc self._top_leve_dir should be reverted to it's previous value

    "so when discover is called the original value should be stored, then discovery done, and then the original restored"

    I'll work on this one.

    He also pointed out that this bugfix should be backported to 2.7 and 3.2

    @igorsobreira
    Copy link
    Mannequin

    igorsobreira mannequin commented Jul 20, 2012

    Updated patch to restore previous value of ._top_level_dir on discover() done. And added a unit test.

    @vstinner
    Copy link
    Member

    This issue is not newcomer friendly, I remove the easy keyword.

    @vstinner vstinner removed the easy label Jul 29, 2019
    @ZackerySpytz ZackerySpytz mannequin added 3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes labels Aug 13, 2019
    @iritkatriel iritkatriel added 3.10 only security fixes 3.11 bug and security fixes and removed 3.7 (EOL) end of life 3.8 only security fixes labels Nov 27, 2021
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @bedevere-app bedevere-app bot mentioned this issue Jan 5, 2024
    Open
    @erlend-aasland erlend-aasland added 3.12 bugs and security fixes 3.13 new features, bugs and security fixes and removed 3.10 only security fixes 3.9 only security fixes labels Jan 5, 2024
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.11 bug and security fixes 3.12 bugs and security fixes 3.13 new features, bugs and security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    Unittest issues
    Status: No status
    Milestone
    No milestone
    Development

    No branches or pull requests
    4 participants
    @vstinner @bitdancer @iritkatriel @erlend-aasland
    X Tutup