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

To document "assertTrue" in unittest #46502

Closed
jcea opened this issue Mar 7, 2008 · 9 comments
Closed

To document "assertTrue" in unittest #46502

jcea opened this issue Mar 7, 2008 · 9 comments
Assignees
Labels
docs Documentation in the Doc dir

Comments

@jcea
Copy link
Member

jcea commented Mar 7, 2008

BPO 2249
Nosy @birkenfeld, @rhettinger, @jcea, @abalkin, @ezio-melotti
Files
  • doc-unittest.diff
  • 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 = 'https://github.com/birkenfeld'
    closed_at = <Date 2008-03-09.15:11:53.377>
    created_at = <Date 2008-03-07.08:39:22.429>
    labels = ['docs']
    title = 'To document "assertTrue" in unittest'
    updated_at = <Date 2011-03-16.03:43:47.380>
    user = 'https://github.com/jcea'

    bugs.python.org fields:

    activity = <Date 2011-03-16.03:43:47.380>
    actor = 'ezio.melotti'
    assignee = 'georg.brandl'
    closed = True
    closed_date = <Date 2008-03-09.15:11:53.377>
    closer = 'georg.brandl'
    components = ['Documentation']
    creation = <Date 2008-03-07.08:39:22.429>
    creator = 'jcea'
    dependencies = []
    files = ['9639']
    hgrepos = []
    issue_num = 2249
    keywords = ['patch']
    message_count = 9.0
    messages = ['63347', '63382', '63385', '63388', '63411', '63416', '63417', '63418', '63420']
    nosy_count = 6.0
    nosy_names = ['georg.brandl', 'rhettinger', 'jcea', 'purcell', 'belopolsky', 'ezio.melotti']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue2249'
    versions = ['Python 2.6', 'Python 2.5', 'Python 2.4']

    @jcea
    Copy link
    Member Author

    jcea commented Mar 7, 2008

    Python 2.4 and 2.5 unittest includes a "assertTrue" method undocumented.
    Document it.

    It is the same method as "assert_" and "failUnless", but the name seems
    clearer.

    @jcea jcea added the docs Documentation in the Doc dir label Mar 7, 2008
    @rhettinger
    Copy link
    Contributor

    I prefer that this remain undocumented. The published API is already
    too fat. This would make it fatter without adding functionality.

    @birkenfeld
    Copy link
    Member

    I agree with Raymond. Having three names for a function is even more
    un-Zen than two.

    Also, I can't see wha'ts clearer in assertTrue in comparison with assert_.

    @purcell
    Copy link
    Mannequin

    purcell mannequin commented Mar 8, 2008

    I could be convinced either way here, and Georg & Raymond always have
    excellent judgement.

    My personal inclination would probably be to add the documentation for
    assertTrue() and also assertFalse(), since their naming is symmetrical
    with that of assertEqual() etc. I think plenty of people are using
    those functions anyway, judging by emails I receive, and I'm not sure
    that leaving the function undocumented addresses the issue of the
    (admittedly) sprawling API.

    (I think Fred Drake put together the documentation originally; I don't
    recall any particular discussion about which aliases to document and
    which to leave out.)

    -Steve

    @jcea
    Copy link
    Member Author

    jcea commented Mar 9, 2008

    I noted the issue while working in bsddb3 module. If failed in python2.3
    because some tests were using "assertTrue". I had to dig where that
    method came from (time lost!) and found that a) it was added in python
    2.4 and b) it is not documented.

    Since "assertTrue" use is "in the wild", being undocumented is a
    inconvenience. Moreover, I think "assertTrue" is far more intuitive and
    cleaner than "assert_" or "failUnless". A personal impression, of
    course. Symmetric with "assertEqual" and so, would be nice.

    I won't insist, in any case :-)

    @abalkin
    Copy link
    Member

    abalkin commented Mar 9, 2008

    FWIW, grepping through Lib/test reveals the following statistics:

    assertFalse: 83
    assertTrue: 97
    failUnless: 684
    assert_: 1977

    Not having assertTrue/assertFalse methods in the Library Reference does
    not discourage people from using them given that they show up without
    any warning in help(). (Moreover, assertTrue shows up before assert_.)

    I would say it should be documented. After all it would only take a two
    line patch (see attached).

    (I agree with OP that assertTrue is clearer than assert_ . Although I
    know that '_' is only there to avoid a conflict with the assert keyword,
    assert_ always stand out as different from the other TestCase methods.)

    @purcell
    Copy link
    Mannequin

    purcell mannequin commented Mar 9, 2008

    +1 for applying Alexander's patch, then; I'll leave the decision to a
    current committer.

    @abalkin
    Copy link
    Member

    abalkin commented Mar 9, 2008

    Just to make the story complete, it should be mentioned that
    assertFalse/True were added because these are the names used by JUnit:

    ------------------------------------------------------------------------
    r34209 | purcell | 2003-09-22 07:08:12 -0400 (Mon, 22 Sep 2003) | 11
    lines
    ..

    • New assertTrue and assertFalse aliases for comfort of JUnit users

    @birkenfeld
    Copy link
    Member

    Okay, I give in :) Committed as r61329.

    @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
    Labels
    docs Documentation in the Doc dir
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants