Assert a method is not called using Mox

Let's say you want to unit test a function and make sure that another function is not called at any point during the routine.

To do it, simply stub out the function you want to assert isn't called, and do not record a call to it before putting the mocks into replay mode.

Here's some example code:

import unittest

import mox


class Mystery(object):
    def want(self):
        pass

    def do_not_want(self):
        pass

    def func(self):
        self.want()


class TestIt(unittest.TestCase):
    def test(self):
        mox = mox.Mox()
        
        m = Mystery()

        # stub out the functions you're interested in verifying
        mox.StubOutWithMock(m, 'want')
        mox.StubOutWithMock(m, 'do_not_want')

        # record calls to stubbed out functions that are
        # expected to be called, in the order expected,
        # as many times as expected
        m.want()

        # set the mocks to replay mode
        mox.ReplayAll()

        # call the function you want to unit test
        m.func()

        # verify the expected calls were made, and the
        # unexpected calls were not made
        mox.VerifyAll()

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

The above code yields the result:

.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

If we update class Mystery to:

class Mystery(object):
    def want(self):
        pass

    def do_not_want(self):
        pass

    def func(self):
        self.want()
        self.do_not_want()

We get this result instead:

F
======================================================================
FAIL: test (__main__.TestIt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "notcalled.py", line 28, in test
    m.func()
  File "notcalled.py", line 14, in func
    self.do_not_want()
  File "/Library/Python/2.6/site-packages/mox.py", line 765, in __call__
    return mock_method(*params, **named_params)
  File "/Library/Python/2.6/site-packages/mox.py", line 1002, in __call__
    expected_method = self._VerifyMethodCall()
  File "/Library/Python/2.6/site-packages/mox.py", line 1049, in _VerifyMethodCall
    expected = self._PopNextMethod()
  File "/Library/Python/2.6/site-packages/mox.py", line 1035, in _PopNextMethod
    raise UnexpectedMethodCallError(self, None)
UnexpectedMethodCallError: Unexpected method call do_not_want.__call__() -> None

----------------------------------------------------------------------
Ran 1 test in 0.008s

FAILED (failures=1)

Mock a socket timeout with HTTPretty

Let's say you have a client that raises MyClientTimeoutException if the underlying socket connect times out. You can unit test this by using the HTTPretty library and stubbing out socket. This example uses Mox.

import socket
import unittest

from httpretty import HTTPretty, httprettified
import stubout

class Test(unittest.TestCase):
    def setUp(self):
        super(Test, self).setUp()
        self.stubs = stubout.StubOutForTesting()

    def tearDown(self):
        super(Test, self).tearDown()
        self.stubs.UnsetAll()
        self.stubs.SmartUnsetAll()

    @httprettified
    def test_timeout_call(self):
        client = MyClient()
        HTTPretty.register_uri(HTTPretty.GET, "http://foo/")

        # fake a timeout
        def fake_create_connection(address, timeout):
            raise socket.timeout('timeout')

        self.stubs.Set(socket, 'create_connection', fake_create_connection)
        self.assertRaises(MyClientTimeoutException,
                          client.call,
                          "http://foo/")

Python Slicing and Copies

I've seen concern a number of times, on blogs or in code reviews, that slicing lists in Python negatively impacts performance, especially when dealing with large data. The concern is about objects being copied as a result of slicing.

I hadn't heard of deep copy being the default behavior for, well, anything in any language. So, it surprised me to think Python would behave like that and I started looking around for information. I could have done my own test initially instead, but I'm relatively new to Python and didn't immediately know how.

It took awhile to find anything. It's one of those things where probably most people know it, but those who don't aren't corrected often.

Anyway, I found in the introductory documentation on lists that "... slice operations return a new list containing the requested elements. This means that the following slice returns a shallow copy of the list..." A shallow copy means that only object references are copied. Strings behave the same way when sliced, probably because lists and strings are both sequence types.

Now, to an example I could have used instead of searching for documentation:

class String(object):
    def __init__(self, value):
        self.value = value

    def __repr__(self):
        a = []
        for c in self.value:
            a.append('%c [%s]' % (c, hex(id(c))))
        return ''.join([self.value, ': ', repr(a)])

s0 = String('OHAY')
print s0
s1 = String(s0.value[:1])
print s1
s2 = String(s0.value[1:])
print s2

And the output:

OHAY: ['O [0x100453a80]', 'H [0x1004d0780]', 'A [0x1004d07b0]', 'Y [0x1004d0840]']
O: ['O [0x100453a80]']
HAY: ['H [0x1004d0780]', 'A [0x1004d07b0]', 'Y [0x1004d0840]']

You can see from the object identities that only the references are copied, not the objects. This is generally inexpensive, that is, it's unlikely to hurt overall performance. Always measure first before trying to optimize.

Labels Containing Symbols are Not Searchable

I don't know how it took me this long to notice, but here on blogger.com, labels containing symbols are broken in that they can't be searched. I have used the label "c++" in the past for a couple of my posts and today when I clicked the search link for the "c++" label, it gave the message "No posts with label c++." instead of returning the labeled posts. I have changed to use "cplusplus" instead until there's hopefully a fix.

It took me a little while to find where I could report a bug and I opened this one.

Here's the link for reporting problems and bugs if you have any.