title: How do I handle multiple asserts within a single Python unittest?
body: <p>This is a problem that came up when performing a single test that had multiple independent failure modes, due to having multiple output streams.  I also wanted to show the results of asserting the data on all those modes, regardless of which failed first.  Python's unittest has no such feature outside of using a Suite to represent the single test, which was unacceptable since my single test always needed to be run as a single unit; it just doesn't capture the nature of the thing.</p>
  
  <p>A practical example is testing an object that also generates a log.  You want to assert the output of it's methods, but you also want to assert the log output.  The two outputs require different tests, which can be neatly expressed as two of the stock asserts expressions, but you also don't want the failure of one to hide the possible failure of the other within the test.  So you really need to test both at the same time.</p>
  
  <p>I cobbled together this useful little widget to solve my problem.</p>
  
  <pre><code>def logFailures(fnList):
      failurelog = []
      for fn in fnList:
          try:
              fn()
          except AssertionError as e:
              failurelog.append("\nFailure %d: %s" % (len(failurelog)+1,str(e)))
  
      if len(failurelog) != 0:
          raise AssertionError(
              "%d failures within test.\n %s" % (len(failurelog),"\n".join(failurelog))
          )
  </code></pre>
  
  <p>Which is used like so:</p>
  
  <pre><code>def test__myTest():
      # do some work here
      logFailures([
          lambda: assert_(False,"This test failed."),
          lambda: assert_(False,"This test also failed."),
      ])
  </code></pre>
  
  <p>The result is that logFailures() will raise an exception that contains a log of all the assertions that were raised in methods within the list.</p>
  
  <p><strong>The question:</strong> While this does the job, I'm left wondering if there's a better way to handle this, other than having to go to the length of creating nested suites of tests and so forth?</p>