This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: To document "assertTrue" in unittest
Type: Stage:
Components: Documentation Versions: Python 2.4, Python 2.6, Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: belopolsky, ezio.melotti, georg.brandl, jcea, purcell, rhettinger
Priority: normal Keywords: patch

Created on 2008-03-07 08:39 by jcea, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
doc-unittest.diff belopolsky, 2008-03-09 13:45
Messages (9)
msg63347 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2008-03-07 08:39
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
msg63382 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-03-08 04:32
I prefer that this remain undocumented.  The published API is already 
too fat.  This would make it fatter without adding functionality.
msg63385 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-03-08 09:38
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_.
msg63388 - (view) Author: Steve Purcell (purcell) (Python triager) Date: 2008-03-08 09:54
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.)

msg63411 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2008-03-09 10:10
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 :-)
msg63416 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-09 13:45
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.)
msg63417 - (view) Author: Steve Purcell (purcell) (Python triager) Date: 2008-03-09 14:07
+1 for applying Alexander's patch, then; I'll leave the decision to a 
current committer.
msg63418 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-03-09 14:26
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 
- New assertTrue and assertFalse aliases for comfort of JUnit users
msg63420 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-03-09 15:11
Okay, I give in :) Committed as r61329.
Date User Action Args
2022-04-11 14:56:31adminsetgithub: 46502
2011-03-16 03:43:47ezio.melottisetnosy: + ezio.melotti
2008-03-09 15:11:53georg.brandlsetstatus: pending -> closed
resolution: wont fix -> fixed
messages: + msg63420
2008-03-09 14:26:34belopolskysetmessages: + msg63418
2008-03-09 14:07:10purcellsetmessages: + msg63417
2008-03-09 13:45:54belopolskysetfiles: + doc-unittest.diff
nosy: + belopolsky
messages: + msg63416
keywords: + patch
2008-03-09 10:10:10jceasetmessages: + msg63411
2008-03-08 09:54:25purcellsetmessages: + msg63388
2008-03-08 09:38:40georg.brandlsetstatus: open -> pending
resolution: wont fix
messages: + msg63385
2008-03-08 04:32:05rhettingersetnosy: + rhettinger
messages: + msg63382
2008-03-07 22:29:52benjamin.petersonsetnosy: + purcell
2008-03-07 08:39:44jceasetversions: + Python 2.4
2008-03-07 08:39:22jceacreate