Navigation Menu

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

Change in expectedFailure breaks testtools #64886

Closed
warsaw opened this issue Feb 19, 2014 · 8 comments
Closed

Change in expectedFailure breaks testtools #64886

warsaw opened this issue Feb 19, 2014 · 8 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@warsaw
Copy link
Member

warsaw commented Feb 19, 2014

BPO 20687
Nosy @warsaw, @pitrou, @larryhastings, @rbtcollins, @ezio-melotti, @voidspace, @csabella
Files
  • test_expected_failure.py
    		•

    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 2019-02-21.02:45:08.279>
created_at = <Date 2014-02-19.18:20:23.409>
labels = ['type-bug', 'library']
title = 'Change in expectedFailure breaks testtools'
updated_at = <Date 2019-02-21.02:45:08.278>
user = 'https://github.com/warsaw'

    bugs.python.org fields:

    activity = <Date 2019-02-21.02:45:08.278>
actor = 'cheryl.sabella'
assignee = 'none'
closed = True
closed_date = <Date 2019-02-21.02:45:08.279>
closer = 'cheryl.sabella'
components = ['Library (Lib)']
creation = <Date 2014-02-19.18:20:23.409>
creator = 'barry'
dependencies = []
files = ['34144']
hgrepos = []
issue_num = 20687
keywords = []
message_count = 8.0
messages = ['211636', '211639', '211640', '211689', '211690', '211718', '211748', '336177']
nosy_count = 9.0
nosy_names = ['barry', 'pitrou', 'larry', 'rbcollins', 'ezio.melotti', 'Arfrever', 'michael.foord', 'thomir', 'cheryl.sabella']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue20687'
versions = ['Python 3.5']
    @warsaw
    Copy link
    Member Author

    warsaw commented Feb 19, 2014

    The change for issue bpo-16997 82844:5c09e1c57200 introduced a regression with testtools. See attached file and instructions for reproducing it (it requires the testtools package).

    @warsaw warsaw added the stdlib Python modules in the Lib dir label Feb 19, 2014
    @rbtcollins
    Copy link
    Member

    I concur that this is a regression - "

    unittest.expectedFailure()
    Mark the test as an expected failure. If the test fails when run, the test is not counted as a failure.

    "

    is in the public docs for the unittest module, and depending on a private attribute to be set is a bit of an abstraction violation - at the least it should handle it not being set (for any older test unittest compatible testcase object).

    @warsaw
    Copy link
    Member Author

    warsaw commented Feb 19, 2014

    Bumping to release blocker so Larry can make a determination.

    @ezio-melotti ezio-melotti added the type-bug An unexpected behavior, bug, or error label Feb 19, 2014
    @larryhastings
    Copy link
    Contributor

    So here's the thing. It only works in Python 3.3 because testtools depends on internal implementation details of unittest, specifically a private exception ("unittest.case._UnexpectedSuccess"). The public interface still works fine. So I don't think this is a regression. If testtools is willing to release hacks depending on undocumented internal behavior, I don't think it's unreasonable for them to rework their hack to support Python 3.4.

    That said, it might be nice to not break testtools if we can avoid it. Antoine: would it be reasonable to rework the implementation of subTest in a way that permitted us to revert the changes to expectedFailure?

    @rbtcollins
    Copy link
    Member

    Oh! I didn't realise it was due to us looking at a private exception - I haven't been given a traceback to review, just the statement of a problem.... We shouldn't have done that(and *Definitely* should have filed a bug that we needed to).

    So - I think the question should become 'can we cope with this in testtools' - we'll issue a point release to ensure compat, assuming it's at all possible.

    @pitrou
    Copy link
    Member

    pitrou commented Feb 20, 2014

    Antoine: would it be reasonable to rework the implementation of
    subTest in a way that permitted us to revert the changes to
    expectedFailure?

    I can't tell you for sure, but certainly not in an easy way. Expected failures were the most delicate feature to keep compatible when adding subtests.
    (in other words: not for 3.4, IMO)

    @larryhastings
    Copy link
    Contributor

    Then I'm marking this as 3.5 and clearing the regression keyword. From here we can either fix it in 3.5 or not bother (and just close this issue as wontfix).

    @csabella
    Copy link
    Contributor

    Larry suggested closing this as wontfix 5 years ago. Since testtools added code for this test and there hasn't been any other changes since, I'll close per his suggestion.

    @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 type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    6 participants
    @warsaw @rbtcollins @pitrou @larryhastings @csabella @ezio-melotti