Skip to content

To document "assertTrue" in unittest #46502

Closed

Description

@jcea
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']

    Activity

    1. jcea commented on Mar 7, 2008

      @jcea
      MemberAuthor

      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.

    2. added
      docsDocumentation in the Doc dir
      on Mar 7, 2008
    3. rhettinger commented on Mar 8, 2008

      @rhettinger
      Contributor

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

    4. birkenfeld commented on Mar 8, 2008

      @birkenfeld
      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_.

    5. purcell commented on Mar 8, 2008

      purcellmannequin
      Mannequin

      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

    6. jcea commented on Mar 9, 2008

      @jcea
      MemberAuthor

      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 :-)

    7. abalkin commented on Mar 9, 2008

      @abalkin
      Member

      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.)

    8. purcell commented on Mar 9, 2008

      purcellmannequin
      Mannequin

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

    9. abalkin commented on Mar 9, 2008

      @abalkin
      Member

      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
    10. birkenfeld commented on Mar 9, 2008

      @birkenfeld
      Member

      Okay, I give in :) Committed as r61329.

    11. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    docsDocumentation in the Doc dir

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions