Checking if something is callable or async callable in Python
I wanted a mechanism to check if a given Python object was "callable" - could be called like a function - or "async callable" - could be called using .
24 posts tagged “pytest”.
I wanted a mechanism to check if a given Python object was "callable" - could be called like a function - or "async callable" - could be called using .
I'm a big fan of snapshot testing - writing tests where you compare the output of some function to a previously saved version, and can re-generate that version from scratch any time something changes.
Take for example an API endpoint that returns something like this: I want to efficiently assert against the second two keys, but I don't want to hard-code the SQLite version into my test in case it…
For sqlite-utils 364 I needed to write a test for a Click app which dealt with input streamed to standard input.
For s3-ocr issue 21 I needed to write a test that simulates what happens when Amazon Textract returns a "LimitExceededException".
I wrote this test to exercise some httpx code today, using pytest-mock. The key was to use which patches the module that was imported by the module.
pytest-recording is a neat pytest plugin that makes it easy to use the VCR library, which helps write tests against HTTP resources by automatically capturing responses and baking them into a YAML file…
I habitually use the fixture in pytest to get a temporary directory that will be cleaned up after each test, but that doesn't work with - which can be used to ensure an expensive fixture is run only…
I wanted to use a fixture with that was itsef as function, so that it could execute statements. Since I'm using a file containing I had to use the fixture to get this to work.
I was seeing this warning in a Django project when I thought I was correctly using timezone-aware dates everywhere: RuntimeWarning: DateTimeField Shift.shift start received a naive datetime…
I'm writing some code that accepts webhooks from Stripe. I wanted to simulate hits to this endpoint in my Django tests.
While working on this issue I figured out a neat pattern for running the tests for my project locally against a specific Python version using uv run: The new-to-me trick here is that works for adding…
This tweet from \@Mariatta tipped me off to the ability to measure "contexts" when running coverage - as a way to tell which tests exercise which specific lines of code.
I wanted to start an actual server process, run it for the duration of my pytest session and shut it down at the end. Here's the recipe I came up with.
While implementing more finely-grained permissions for (issue 8) I decided I wanted to register a Datasette pluggy plugin for the duration of a single test.
For apple-notes-to-sqlite I needed to write some tests that simulated executing the command using the Python module. I wanted my tests to run on Linux CI machines, where that command would not exist.
My test suite for Datasette has grown so large that running the whole thing sometimes causes me to run out of file handles.
I'm writing some quite complex pytest parameterized tests this morning, and I was finding it a little bit hard to read the test cases as the number of parameters grew.
I needed to write a test that checked for a really complex sequence of mock calls for s3-credentials 3.
I usually build command-line tools using Click (and my click-app cookiecutter template), which includes a really nice set of tools for writing tests.