How do you do it then?

from distutils.util import strtobool as _bool
import os

BEHAVE_DEBUG_ON_ERROR = _bool(os.environ.get("BEHAVE_DEBUG_ON_ERROR",
                                             "no"))
def after_step(context, step):
    if BEHAVE_DEBUG_ON_ERROR and step.status == 'failed':
        import pudb
        pudb.post_mortem(tb=step.exc_traceback,
                         e_type=None,
                         e_value=None)
    return

distutils.util.strtobool(val)

Convert a string representation of truth to true (1) or false (0).

• True values are y, yes, t, true, on and 1
• false values are n, no, f, false, off and 0
• Raises ValueError if val is anything else.

set -x BEHAVE_DEBUG_ON_ERROR yes

So, what then?

set -x <variable> <value>

set -e <variable>

Conclusion

Background

I wanted to check to make sure I was sending the right output to the screen so I thought I would use mock to catch what I was sending to it. These are some notes about what happened.

Mocking print

If you try to patch print with MagicMock, here is what you get.

from mock import MagicMock, patch, call

mock_print = MagicMock()
try:
    with patch('print', mock_print):
        print 'test'
except TypeError as error:
    print error

Need a valid target to patch. You supplied: 'print'

So it looks like 'print' is not the right thing to patch. Maybe you need to call it a built-in funtion:

with patch('__builtin__.print', mock_print):
    print 'test'

print mock_print.mock_calls

test
[]

What if you call it as a function?

with patch('__builtin__.print', mock_print):
    print( 'test')

print mock_print.mock_calls

test
[]

So neither of those raise an error, but they also do not manage to mock print. Well, if you look at the description for print, it turns out that the print function has the signature:

print(*objects, sep=' ', end='\n', file=sys.stdout)

It also says that the function call is not normally available unless you import it from the future.

But, presuming that the print statement works the same way as the function call, what happens if you mock sys.stdout?

Mocking sys.stdout

This doesn't answer the question of why I can't mock print directly, but maybe mocking sys.stdout will work instead.

with patch('sys.stdout', mock_print):
    print 'test'

expected = [call('test')]
actual = mock_print.mock_calls

try:
    assert actual == expected, "Expected: {0} Actual: {1}".format(expected,
                                                                  actual)
except AssertionError as error:
    print error

Expected: [call('test')] Actual: [call.write('test'), call.write('\n')]

It looks like the mock works this time, but it did not return what I was expecting -- print makes two calls to stdout.write, the first is the string you pass it which it then follows with a newline character. Given this slightly more complete understanding of print:

# create some output to send to print
lines = "a b c".split()

# reset the mock so the previous calls are gone
mock_print.reset_mock()
with patch('sys.stdout', mock_print):
    for line in lines:
        print line

expected = []
for line in lines:
    expected.append(call.write(line))
    expected.append(call.write('\n'))

actual = mock_print.mock_calls

try:
    assert actual == expected, "Expected: {0} Actual: {1}".format(expected,
                                                                  actual)
except AssertionError as error:
    print error

Conclusion

Not earth-shattering, but I thought it was interesting that even after using Python for years, something as basic as print can yield something new if looked at more closely. It was also useful to see how mock can be used to discover the calls that are being made on an object, not just to test that expected calls are being made.

sys.argv Calls

Using the mock_calls list from mock can be useful in figuring out how an object is being used.

parser = argparse.ArgumentParser()
parser.add_argument('--debug', action='store_true')
parser.add_argument('-d')

sys = MagicMock()
with patch('sys.argv', sys):
    args = parser.parse_args()
for item in sys.mock_calls:
    print item
print args

call.__getitem__(slice(1, None, None))
call.__getitem__().__iter__()
call.__getitem__().__getitem__(slice(0, None, None))
call.__getitem__().__getitem__().__iter__()
call.__getitem__().__getitem__().__len__()
Namespace(d=None, debug=False)

The getitem and slice

The first thing to note is the __getitem__ calls. According to the documentation it is:

Called to implement evaluation of self[key]. For sequence types, the accepted keys should be integers and slice objects.

So it looks like it is first using the built-in slice function to get a particular argument. According to the documentation the arguments are the same as for the range function (start, stop, step).

So it looks like it is doing the equivalent of [1:] in the first slice:

test = [0,1,2]

# what does it do?
print test.__getitem__(slice(1, None, None))

# are they the same?
print test[1:] == test.__getitem__(slice(1, None, None))

[1, 2]
True

One thing to note is that slice(1) is not the same thing as slice(1, None, None):

print slice(1)
print slice(1, None, None)

slice(None, 1, None)
slice(1, None, None)

Trying a lambda

So, if I give __getitem__ a function to return the arguments I want, will this work?

sys.__getitem__ = lambda x,y: ['--debug']
with patch('sys.argv', sys):
    args = parser.parse_args()
for item in sys.mock_calls:
    print item

print args

call.__getitem__(slice(1, None, None))
call.__getitem__().__iter__()
call.__getitem__().__getitem__(slice(0, None, None))
call.__getitem__().__getitem__().__iter__()
call.__getitem__().__getitem__().__len__()
Namespace(d=None, debug=True)

It looks like it does, but would it be better to just make argv a list?

argv as a list

args = ['--debug']

def getitem(index):
    return args[index]

# make a new mock since I set __getitem__ to a  lambda function
sys = MagicMock()
sys.__getitem__.side_effect = getitem

with patch('sys.argv', sys):
    parsed_args = parser.parse_args()

for item in sys.mock_calls:
    print item
print parsed_args

call.__getitem__(slice(1, None, None))
Namespace(d=None, debug=False)

It now does not make the other calls and it also does not set the debug to True, so it did not work.

But I seem to have forgotten my earlier slice check -- it is starting at the second item. I think that normally the name of the program is the first thing passed in so maybe there needs to be an extra (first) entry to simulate the command name.

Adding a Command Name

args = 'commandname --debug'.split()

def getitem(index):
    return args[index]

sys.__getitem__.side_effect = getitem

with patch('sys.argv', sys):
    parsed_args = parser.parse_args()

for item in sys.mock_calls:
    print item
print parsed_args

call.__getitem__(slice(1, None, None))
call.__getitem__(slice(1, None, None))
Namespace(d=None, debug=True)

It looks like it worked, and all but the first two calls went away, so it perhaps they were a result of me using the mock, not a normal part of the way parse_args works.

The Whole Thing

Okay, but what about the option -d?

args = 'commandname -d cow --debug'.split()

def getitem(index):
    return args[index]

sys.__getitem__.side_effect = getitem

with patch('sys.argv', sys):
    try:
        parsed_args = parser.parse_args()
    except Exception as error:
        print error

for item in sys.mock_calls:
    print item
print parsed_args

call.__getitem__(slice(1, None, None))
call.__getitem__(slice(1, None, None))
call.__getitem__(slice(1, None, None))
Namespace(d='cow', debug=True)

Well, that was kind of painful. On the one hand, I got it to work, on the other hand, I do not really know what the slice is doing since it seems to slice the same items over and over. I think, looking at the first set of calls, after the initial slice it manipulates the sliced copy and since I am passing a real list instead of a mock, the calls are now hidden.

Looking at the Code

I downloaded the python 2.7 code and looked in argparse.py and found this:

def parse_args(self, args=None, namespace=None):
    args, argv = self.parse_known_args(args, namespace)

There is more to that function, but since it is calling parse_known_args I jumped to it:

def parse_known_args(self, args=None, namespace=None):
    if args is None:
        # args default to the system args
        args = _sys.argv[1:]

Once again there is more code after that, but this explains the slice that is seen in the calls.

Later on it calls:

namespace, args = self._parse_known_args(args, namespace)

So jumping to _parse_known_args:

arg_strings_iter = iter(arg_strings)
for i, arg_string in enumerate(arg_strings_iter):

which I think explains the __iter__ call in the first set of calls. I tried stepping through the code with pudb but could only find one slice, I am not sure what the other calls were for. I suppose it would have been smarter to look at the source code first, but this is about figuring out how to use mock so I think it was helpful to try it empirically first. No fair peeking in the back of the book until you have tried at least once.