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.

Sign up for GitHub

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

Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times #51714

Closed
awaltman mannequin opened this issue Dec 10, 2009 · 3 comments
Closed

Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times #51714

awaltman mannequin opened this issue Dec 10, 2009 · 3 comments
Labels
stdlib Python modules in the Lib dir tests Tests in the Lib/test dir type-bug An unexpected behavior, bug, or error

Comments

@awaltman
Copy link
Mannequin

awaltman mannequin commented Dec 10, 2009

BPO 7465
Nosy @bitdancer
Files
  • unittest_doesnt_reinstantiate_members.txt: Code and output
    		•

    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 = <Date 2009-12-10.02:42:22.502>
created_at = <Date 2009-12-10.02:20:55.156>
labels = ['tests', 'type-bug', 'library', 'invalid']
title = "Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times"
updated_at = <Date 2009-12-10.02:46:30.978>
user = 'https://bugs.python.org/awaltman'

    bugs.python.org fields:

    activity = <Date 2009-12-10.02:46:30.978>
actor = 'r.david.murray'
assignee = 'none'
closed = True
closed_date = <Date 2009-12-10.02:42:22.502>
closer = 'r.david.murray'
components = ['Library (Lib)', 'Tests']
creation = <Date 2009-12-10.02:20:55.156>
creator = 'awaltman'
dependencies = []
files = ['15514']
hgrepos = []
issue_num = 7465
keywords = []
message_count = 3.0
messages = ['96189', '96192', '96193']
nosy_count = 2.0
nosy_names = ['r.david.murray', 'awaltman']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue7465'
versions = ['Python 2.6']
    @awaltman
    Copy link
    Mannequin Author

    awaltman mannequin commented Dec 10, 2009

    Not sure if this is intended behavior. I have a baseClass I'm writing
    tests for. My test architecture has an instance of this baseClass
    assigned as a member of TestBaseClass(unittest.TestCase) in
    TestBaseClass.setUp.

    The problem occurs when tests in TestBaseClass modify state within the
    member baseClass instance. I think there should be a fresh new instance
    of baseClass for every test that gets run, but the old state from the
    last test is still there.

    Example code and output from Python 2.6.2 attached.

    @awaltman awaltman mannequin added stdlib Python modules in the Lib dir tests Tests in the Lib/test dir labels Dec 10, 2009
    @awaltman awaltman mannequin changed the title Call to another class's constructor in unittest.TestCase.setUp returns the same instance Call to another class's constructor in unittest.TestCase.setUp returns the same instance multiple times Dec 10, 2009
    @bitdancer
    Copy link
    Member

    Yes, this working as intended. Consider:

    Python 2.7a1+ (trunk:76725, Dec  9 2009, 09:26:36)
[GCC 4.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class baseClass(object):
...     def __init__(self, testList=[]):
...         self.testList = testList
...     def insertItem(self):
...         self.testList.append("testing from baseClass")
...
>>> a = baseClass()
>>> b = baseClass()
>>> del b
>>> a.insertItem()
>>> print a.testList
['testing from baseClass']
>>> b = baseClass()
>>> print b.testList
['testing from baseClass']

    See
    http://docs.python.org/faq/design.html#why-are-default-values-shared-between-objects
    for an explanation of why.

    @bitdancer bitdancer added invalid type-bug An unexpected behavior, bug, or error labels Dec 10, 2009
    @bitdancer
    Copy link
    Member

    Heh, that first b = baseClass(); del b wasn't supposed to be there and
    doesn't change the result, just in case you were wondering.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    stdlib Python modules in the Lib dir tests Tests in the Lib/test dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @bitdancer