Since Python 2.7 you can use context manager to get ahold of the actual Exception object thrown:

import unittest

def broken_function():
    raise Exception('This is broken')

class MyTestCase(unittest.TestCase):
    def test(self):
        with self.assertRaises(Exception) as context:
            broken_function()

        self.assertTrue('This is broken' in context.exception)

if __name__ == '__main__':
    unittest.main()

assertRaises

In Python 3.5, you have to wrap context.exception in str, otherwise you'll get a TypeError

self.assertTrue('This is broken' in str(context.exception))

If your class (that defines the test_auth_failure method) extends unittest.TestCase, you should use [Python.Docs]: unittest - assertRaises(exception, callable, *args, **kwds):

Replace your try / except clause by:

with self.assertRaises(exceptions.HTTPUnauthorized):
    self.api.auth()

or

self.assertRaises(exceptions.HTTPUnauthorized, self.api.auth)

Exception handling and unit testing solve different problems:

• Exception Handling: Allows a running program to recover from an exceptional condition (like expecting to be able to open a file but it is open in another program).
• Unit Tests: Tests the behavior of small parts (units) of your program to make sure they behave the way you expect.

Exception handling is a run time concern, while unit tests are a build time concern.

The two can work together. For example, let's say you have a utility that attempts to move files from one place to another, and verify that they are bit for bit the same. In your utility, you need to scan for the available files, and then work on them one by one.

A number of things can cause the utility to not be able to copy a file:

• The file is in use by another process
• You do not have permissions to delete the file from its present location, or write it to the destination
• If you have more than one utility running at once, the file could be gone by the time you get to it in your loop

Those are all exceptions. You have to decide whether any of those exceptions should cause your utility to stop processing. For example, the final exception is something we don't want to stop prematurely with, and it is probably OK to skip a file if another process has it. The permissions thing really prevents your utility from doing its job, so you'll need to stop if that's the case.

In your unit tests, you would set up a scenario where each of those conditions would be met, and then assert that the application behaves appropriately:

• Unit test 1 sets up a source and destination directory where everything is set up for a successful copy. It works, no exception handling required!
• Unit test 2 sets up a source and destination directory, and then puts a lock on the source file. It fails, so you need to add exception handling to your utility to handle the lock (i.e. skip the existing file and move on
• Unit test 3-5 sets up source and destination directory and a source file, but changes the permissions (source, destination, both) and asserts that the utility stops as soon as it realizes it can't copy any files. If the exception handling you put in before isn't too broad, then this should work. If not, you have to change your application to make all the tests pass.
• Unit test 6 would be a bit more difficult to instrument since you would need to know when the source directory scan is complete, but it would set up source and destination directories, source file and then delete the source file after the scan is complete but before the move operation was performed. If the application ends early it fails, so you need to add exception handling, or at least an exists check before the copy/verify/delete operation is complete.

As you can see they are not mutually exclusive concepts to improve your application. However, they serve very different purposes.

I will say using exception handling where a simple if statement is more appropriate, you should change your code. In the example you provided there was a snippet that looked like this:

    try:
        assert self.turn >= 0
    except ValueError:
        print('turn number must be positive')

That would be a misapplication of an assert, particularly because you are not letting the exception leave the method. That could would be much cleaner, and execute faster (especially in loops) like this:

    if selt.turn < 0:
        print('turn number must be positive')

That code provides the same effect in a more readable way, that doesn't have the overhead of exception handling. Exception handling is expensive.

Now, if you wanted that to be an exceptional case that stops the game because now the game is in an undetermined state, you should not catch the exception in that code, and let whoever is calling the code deal with it. That would simply look like this:

    assert(self.turn >= 0, 'turn number must be positive')