Python unittest - opposite of assertRaises?

def run_test(self):    try:        myFunc()    except ExceptionType:        self.fail("myFunc() raised ExceptionType unexpectedly!")

Hi - I want to write a test to establish that an Exception is not raised in a given circumstance.

That's the default assumption -- exceptions are not raised.

If you say nothing else, that's assumed in every single test.

You don't have to actually write an any assertion for that.

Just call the function. If it raises an exception, the unit test framework will flag this as an error. You might like to add a comment, e.g.:

sValidPath=AlwaysSuppliesAValidPath()# Check PathIsNotAValidOne not thrownMyObject(sValidPath)

Edited to add clarifications from the comments:

• Unit tests can have 3 results: Pass, Fail, Error. (Actually more if you count XPass/XFail/Skip...)
• If you're testing a particular exception is not thrown, and it is thrown, then in theory that should be a Fail. But the code above makes it an Error, which is theoretically "wrong".
• As a practical matter, with an Error your test runner will probably print the stack trace, which may be useful debugging the failure. With a Fail you probably won't see the stack trace.
• As a practical matter, with a Fail you can mark the test as "Expected to Fail". With an Error you probably can't do that, although you can mark the test as "skip".
• As a practical matter, making the test case report an Error requires additional code.
• Whether the difference between "Error" and "Failure" matters depends on your processes. The way my team uses unit tests, they have to all pass. (Agile programming, with a continuous integration machine that runs all the unit tests). What actually matters to my team is "do all the unit tests pass?" (i.e. "is Jenkins green?"). So for my team, there's no practical difference between "Fail" and "Error".
• Due to the advantages mentioned above (less code, seeing the stack trace), and the fact that Fail/Error are treated the same by my team, I use this approach.
• You may have different requirements if you use your unit tests in a different way, especially if your processes treat "fail" and "error" differently, or if you want to be able to mark tests as "expected failure".
• If you would rather have this test report an Error, use DGH's answer.