As a follow up to Python Mocking 101: Fake It Before You Make It, this post covers some higher-level software engineering principles demonstrated in our Python testing over the past year and half. In particular, the idea of patching mock objects in unit tests is revisited and explored in greater depth.

When your metrics report that a Python component is experiencing random restarts and instability after a few days of uptime, what do you do? In our case, looking at memory usage showed that a component's memory footprint increased monotonically and continuously, indicating a memory leak. A powerful memory tracking tool in the Python standard library, tracemalloc, made it possible to diagnose and fix the leak quickly. In this post, we'll look at how we used it.

Implementation of cryptographic hashes is theoretically not that hard, given a good cryptographic library. However, things get trickier when we want to allow dependency cycles. At that point, we get a bit of a chicken-and-egg problem. We need resource A’s hash to compute resource B’s hash, but that in turn depends on B’s hash again! Let's study the problem and solve it.

For some time, we’ve been using AWS Lambda with SNS topics and votebots, but we hadn’t tried anything big with it. Until now. The Serverless framework gave us the push we needed. Our goal? To power an application useful to a business function via an API built with AWS Lambda and API Gateway, harming no EC2 instances in the process.

In Python, mocking is accomplished through the unittest.mock module. The module contains a number of useful classes and functions, the most important of which are the patch function (as decorator and context manager) and the MagicMock class. Mocking in Python is largely accomplished through the use of these two powerful components.

Despite obstacles and hesitations, the benefits of functional programming are immense. The key is this: language guarantees make code more robust, help to mitigate errors, and eliminate entire classes of bugs.

Jared's article in this month's issue of PragPub, The Pragmatic Bookshelf's magazine affiliation, is a helpful read if you're interested in functional programming and Haskell in particular.

We knew Python was the right choice, but we had lingering doubts about our decision to continue avoiding Python 3. After taking a closer look, we found that things had changed drastically since the last time we'd seriously considered this question, and the scale was no longer decidedly tipped against Python 3.