[Python-Dev] PEP: Frequently-requested additional features for the unittest module (original) (raw)

Scott David Daniels Scott.Daniels at Acm.Org
Thu Jul 17 06:48:50 CEST 2008

Ben Finney wrote:

Scott David Daniels <Scott.Daniels at Acm.Org> writes:>

I would rather something more like:

def assertcomparetrue(op, first, second, msg=None): if op(first, second): return raise self.failureexception(msg) if msg is None: self.failureexception("%(first)r %(op)r %(second)" % vars()) self.failureexception("%(first)r %(op)r %(second): %(msg)" % vars()) I'm confused. It appears to me that your version never gets past the first 'raise' statement, which is unconditional; and the rest seems to do nothing but instantiate exceptions without using them.

Sorry, I was too hasty last time (had to jet out of the house) and sent out the unfinished version. This is what I meant:

  def assert_compare_true(op, first, second, msg=None):
      if op(first, second):
          return
      if msg is None:
          raise self.failure_exception(
                 "%(first)r %(op)r %(second)" % vars())
      raise self.failure_exception(
                 "%(first)r %(op)r %(second): %(msg)" % vars())

(1) Displaying args is the whole point, otherwise just use assert_. This form fosters tests that say what is wrong, and not simply that something has gone wrong. The point is a readable test, reducing boilerplate at the call location. Something like: ... self.assert_le(sum(source) // len(source), 5, "Mean OK")

(2) No point to doing string conversion except on failure; slow repr methods are fine to use if the result is not discarded.

--Scott David Daniels Scott.Daniels at Acm.Org

More information about the Python-Dev mailing list