Jeremy Satterfield
Coding, Brewing and Tulsa Life

Viewing posts for the category development

Using Tox with Travis CI to Test Django Apps

Being a fan of good testing, I'm always trying to find ways to improve testing on various projects. Travis CI and Coveralls are really nice ways to set up continuous integration for your open-source projects. A couple months ago I finally started hearing grumblings about tox and how everyone was it using for their Python test automation. Every time I'd try to wrap my head around it, something always eluded me, so this week I finally decided to dive in head first and see if I could get to the bottom of it and how it could improve my current integration setup.

Mocking Context Managers in Python

I've often found Python's context managers to be pretty useful. They make a nice interface that can handle starting and ending of temporary things for you, like opening and closing a file.

Abusing Django Rest Framework Part 2: Non-rate-based Throttling

Anyone running an API that can be reached by the outside world should most definitely be concerned that someone might pummel their server by making a massive amount of requests to that one endpoint that requires a bunch of on-the-fly calculations. Enter Django Rest Framework's throttling. It allows you to easily configure the framework to stop allowing requests from a user once they've made so many requests in a period of time. Whether you're concerned about requests over a sustained period of time or in short bursts, rate limiting with throttles will handle it.

Abusing Django Rest Framework Part 1: Non-Model Endpoints

When working with Django Rest Framwork a few months back, there were a few road blocks that we ran into. Rest Framwork is awesome with most models for providing a simple CRUD API, in any (or multiple) serializations, with authentication and permissions. Sometimes, however, things aren't so simple. Things get ugly. Framworks get abused.

Finding Un-mocked HTTP requests in Python tests with Nose

I'm a big fan of proper unit testing with mocking. So I'm pretty disappointed when we run across a unit that is not only not mocked properly, but results in real-world consequences outside the testing environment. One case we've run into couple of times now is tests that are making actual outbound HTTP requests to remote servers. Since clients don't necessarily like getting fake information posted to their servers every time you run tests, I figured this was a good time to get to the bottom of this.