posts on PythonTest

Explore Python dependencies with `pipdeptree` and `uv pip tree`

Tue, 11 Nov 2025 07:24:00 +0800

Sometimes you just want to know about your dependencies, and their dependencies.

I’ve been using pipdeptree for a while, but recently switched to uv pip tree.
Let’s take a look at both tools.

pipdeptree

pipdeptree is pip installable, but I don’t want pipdeptree itself to be reported alongside everything else installed, so I usually install it outside of a project. We can use it system wide by:

Installing with uv tool install pipdeptree.
- Then running with pipdeptree --python auto
Running without installing with uvx pipdeptree --python auto

usage

The --python auto tells pipdeptree to look at the current environment.

Announcing the Lean TDD book

Sun, 02 Nov 2025 00:00:00 +0000

There are many great ideas that I’ve gotten from TDD, Lean, Pragmatic, and more. For the past few years, I’ve really wanted to write a book about TDD, with an emphasis on using Lean teachings to cut out all the waste, and then grow TDD into more of a project wide process.

To motivate myself to just get it done finally, I’ve started. And I’m using a holistic project wide process.

Polite lazy imports for Python package maintainers

Sun, 26 Oct 2025 23:13:00 +0800

If you are a maintainer of a Python package, it’s nice if you pay attention to the time it takes to import your package.

Further, if you’ve got a Python package with multiple components where it’s probable that many users will only use part of the package, then it’s super nice if you set up your __init__.py files for lazy importing.

Previously - lazy importing other packages

In Python lazy imports you can use today, I discussed:

Python lazy imports you can use today

Mon, 13 Oct 2025 19:00:00 +0800

There’s a proposal, PEP 810 – Explicit lazy imports for Python to natively support lazy importing starting in Python 3.15.

However, it has not been accepted yet, and even if it is accepted, 3.15 is a year away. What do we do now?

The techniques covered in this post that allow you to use lazy importing NOW with Python 3.13, Python 3.12, …, really every version of Python.

Let’s look at a small code example that imports something.

Installing Python 3.14 on Mac or Windows

Fri, 10 Oct 2025 20:14:00 +0800

The easiest way to install Python 3.14 (or 3.13, 3.12, 3.11, 3.10, 3.10, …)

I originally wrote this post in 2022 for Python 3.11.
From 2022 through 2024, I remained of the belief that installing from python.org was the best option for most people.

However, 2025 changed that for me, with uv and uv python supporting the installation of Python versions. It’s a really pleasant and clean way to keep Python versions up to date and install new versions.

Testing against Python 3.14

Fri, 10 Oct 2025 16:10:00 +0800

Python 3.14 is here.

If you haven’t done so, it’s time to update your projects to test against 3.14.

The following procedure is what I’m following for a handful of projects. Your process of course may be different if you use different tools.

Honestly, I’m partly writing this down so I don’t have to remember it all in a year when 3.15 rolls around.

Installing Python 3.14

Installing with uv

uv self update
uv python install 3.14

While it’s true that creating a virtual environment with uv venv .venv --python 3.14 will install 3.14 if it isn’t already there, you still gotta run uv self update. So I just usually install it while I’m at it.

pytest-check 2.6.0 release

Mon, 06 Oct 2025 21:30:00 +0800

There’s a new release of pytest-check. Version 2.6.0.

This is a cool contribution from the community.

The problem

In July, bluenote10 reported that check.raises() doesn’t behave like pytest.raises() in that the AssertionError returned from check.raises() doesn’t have a queryable value.

Example of pytest.raises():

with pytest.raises(Exception) as e:
    do_something()
assert str(e.value) == "<expected error message>"

We’d like check.raises() to act similarly:

with check.raises(Exception) as e:
    do_something()
assert str(e.value) == "<expected error message>"

But that didn’t work prior to 2.6.0. The issue was that the value returned from check.raises() didn’t have any .value atribute.

Timeline of Selected Software Events

Sat, 13 Sep 2025 00:00:00 +0000

There are a lot of events in the history of software development. This is a list of dates that have some significance in either the stuff I work with or methodologies. I’ve compiled this list for my own benefit in thinking about my history and how these things have led to my current software philosophies.

I’m publishing the list as a “what the heck, why not?” kinda thing. If I’ve gotten something wrong, feel free to contact me.

Python People podcast now at pythontest.com/pythonpeople

Fri, 05 Sep 2025 00:00:00 +0000

Like the recent archival of Test and Code, the Python People podcast has also moved. Python People is now at pythontest.com/pythonpeople.

Is it also archived? As in done?

I don’t think so. I think I might start that up again at some point.

But for now, it’s on a long-ish term pause.

BTW, the RSS feeds for both Python People and Test and Code should be redirected correctly, so you shouldn’t have to change anything in your podcast player.

Test and Code Archive is now available

Mon, 01 Sep 2025 00:00:00 +0000

I really appreciate all of the positive feedback I’ve gotten when I announced that I was stopping the Test & Code podcast. I mean, I didn’t get any “good idea, you that’s a terrible show” feedback, thankfully.
But I did get a lot of people saying that I should keep it alive somehow.

So, it’s now archived here: Test and Code Archive

That link also includes a link to the xml that you need if you want to plop that into the “subscribe via URL” box on really any podcast player.

pytest fixtures nuts and bolts - revisited

Wed, 06 Aug 2025 06:13:00 -0700

In 2013/2014 I wrote a 4 part series on pytest fixtures.
It started out fine-ish. And then by part 4 I crammed way too many concepts into one huge post.

Well, I’ve recently reviewed all of this, and

split the posts into one concept each
made sure all of the info was correct for modern versions of Python and pytest
reran the examples to make sure the output is correct

Here’s the new/old series:

Time Machine back to 2012

Tue, 27 May 2025 00:00:00 +0000

I’m doing some blog cleanup.

New look

I just recently have this shiny new theme for the blog.
I’m really loving the colors, and the ability to shamelessly plug my courses in the right side-bar. (Below the content if you’re reading on mobile).

New analytics

I don’t want to track anyone.

But I do want to know:

which posts are popular
which not so much
what are people 404-ing on

To that end, I was using Netlify server side analytics.
It was ok, but also rather restrictive.

Unravelling t-strings with pytest

Mon, 26 May 2025 09:22:00 +0800

Brett Cannon recently released a great article explaining how Python 3.14’s new t-strings work.

Here’s the article: Unravelling t-strings.

He built up the functionality of how t-strings work in a way that you can follow along even if you don’t have 3.14.0b1 (where t-strings are instroduced), all the way up to the last example.

He walks through

Evaluating the Python expression
Applying specified conversions
Applying format specs
Using an Interpolation class to hold details of replacement fields
Using Template class to hold parsed data

The end result is very close to an example used in PEP 750.

Testing some tidbits with pytest

Mon, 16 Dec 2024 07:00:00 +0800

I noticed a fun post by Ned Batchelder called Testing some tidbits.

The post looks at different ways to see if a string has only 0 or 1 in it.

He posted a few ways on Bluesky/Mastodon and got a bunch of replies with more ways. And then wrote a small script to check to see if they worked.

It’s a fun post, and from it I learned about:

cleandoc - a way to strip leading blank space and maintain code block indentation
partition - splitting strings based on a substring
Using | to pass imports to eval() - I don’t use eval much.

I was a little dissapointed that with a title like “Testing some tidbits”, Ned didn’t use pytest or any other test framework.

Finding the top pytest plugins

Sun, 25 Aug 2024 05:00:00 +0800

What are the top downloaded pytest plugins?
I want to know this. And I’d like the answer updated regularly.
So today I decided to write a script to do that for me.

Grab data

Let’s start with Top PyPI Packages from Hugo van Kemenade. This list is “A monthly dump of the 8,000 most-downloaded packages from PyPI.”

Perfect.

Parse

Now:

Filter for “pytest” in the package name
Remove “pytest” itself.
- I could leave this in for comparison, but it would always be #1.
Renumber.
Include a link to the pypi.org package page.
Throw it all in a table.
Pipe it to a markdown blog page.

Added on 26-Aug:

Grab summaries from pypi.org via Warehouse API.
Thanks Jeff Triplett and Hugo for pointing me in that direction.

pytest 8 is here

Mon, 29 Jan 2024 20:00:00 +0800

pytest 8.0.0 was released on 17-Jan-2024, and I’m pretty excited about it.

I’m not going to cover all fo the changes, I’ll just highlight a few.
For full set of changes, see the pytest changelog:

Version Compatibility

Dropped support for Python 3.7, as it reached EOL last June.

Features and Improvements

Improved Diffs

Improved diffs that pytest prints when an assertion fails, including:

Testing argparse Applications

Thu, 16 Nov 2023 07:20:00 -0800

I was asked recently about how to test the argument parsing bit of an application that used argparse. argparse is a built in Python library for dealing with parsing command line arguments for command line interfaces, CLI’s.

You know, like git clone <repo address>.

git is the application.
<repo address> is a command line argument.
clone is a sub-command.

Well, that might be a bad example, as I’m not going to use subcommands in my example, but lots of this still applies, even if you are using subcommands. Anyway, loads of applications use command line arguments, also sometimes called flags and options.

pytest slow order

Thu, 02 Nov 2023 14:39:00 -0700

I received a question the other day about combining the notion of marking slow tests and ordering them to run the slow tests first.

This post describes a bit of background and a solution to the problem.

@pytest.mark.slow

It’s possible to mark slow tests with @pytest.mark.slow and then either run or skip the slow tests.

To run slow tests: pytest -m slow
To skip slow tests: pytest -m "not slow"

With the pytest-skip-slow plugin, you can:

Upgrading to Python 3.12 and my battle with virtualenv cache

Mon, 02 Oct 2023 12:29:07 -0700

edited Oct 3, 2023 with a new fix and a new understanding of the problem

Initial title was …

Python 3.12 + "AttributeError: module ‘pkgutil’ has no attribute ‘ImpImporter’. Did you mean: ‘zipimporter’?"

This is a tale of upgrading Python 3.12

I ran into this error while I was trying to update a project to test on Python 3.12:

  ...
  File "/Users/okken/Library/Application Support/virtualenv/wheel/house/pip-23.0.1-py3-none-any.whl/pip/_internal/metadata/importlib/_envs.py", line 123, in _find_eggs_in_zip
    from pip._vendor.pkg_resources import find_eggs_in_zip
  File "/Users/okken/Library/Application Support/virtualenv/wheel/house/pip-23.0.1-py3-none-any.whl/pip/_vendor/pkg_resources/__init__.py", line 2164, in <module>
    register_finder(pkgutil.ImpImporter, find_on_path)
                    ^^^^^^^^^^^^^^^^^^^
AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'?

py312: internal error

Specifically:

Sharing is Caring - Sharing pytest Fixtures - PyCascades 2023

Sun, 19 Mar 2023 00:00:00 +0000

Slides and code and such for a talk for PyCascades 2023.

Talk page: Sharing is Caring - Sharing pytest Fixtures
Summary:

pytest rocks, obviously. When people start using pytest as a team, they often come up with cool fixtures that would be great to share across projects. In fact, many great Python packages come pre-loaded with pytest fixtures. This talk describes how easy it is to share fixtures using the pytest plugin model.

pytest tips and tricks

Mon, 27 Feb 2023 00:00:00 +0000

This is a set of tips/tricks for learning and using pytest.
I’ll probably build on the list, so feel free to share with me items you think should be in the list.
Many items really deserve more explanation, and maybe full posts. Let me know if there’s something you’d like more in depth discussion of.

Note: I’m not numbering these, because I don’t want to keep track of order. Also, this is more of a brain dump, and not a prioritized list.

Fixing Circular Imports in Python with Protocol

Mon, 23 Jan 2023 00:00:00 +0000

The problem started when I had two classes that needed to talk to each other. Sometimes, classes need to talk to each other in both directions.

The following example is made up, but mostly behaves like the original problem.

Let’s say I have a Director and an Actor.
The Director tells the Actor to do_action().
In order to do the action, the Actor needs to get_data() from the Director.

Here’s our director.py:

Testing with Python 3.12

Mon, 05 Dec 2022 00:00:00 +0000

Python 3.12.0a2 is out. So now may be a great time to get your projects to start testing against 3.12.

Note about alpha releases of Python

This is from the same link as above: “During the alpha phase, features may be added up until the start of the beta phase (2023-05-08) and, if necessary, may be modified or deleted up until the release candidate phase (2023-07-31). Please keep in mind that this is a preview release and its use is not recommended for production environments.”

Talk - Sharing is Caring - pytest fixture edition

Sat, 10 Sep 2022 00:00:00 +0000

I gave a talk at PyBay 2022 with the above title. It’s about sharing fixtures.

The source code, and the slides, are at github.com/okken/pytest_fixture_sharing.

Current Git CLI workflow

Wed, 13 Apr 2022 00:00:00 +0000

Workflow

Most of my interactions with git CLI, especially for quick changes, is:

$ git checkout main
$ git pull
$ git checkout -b okken_something
< code changes >
$ git commit -a -m 'quick message'
$ git push

Then the code review and merge happen on the server.

Commands

Let’s break that down.

git checkout main
- Start at the main branch.
git pull
- Grab any changes from remote repo.
git checkout -b okken_something
- Create and switch to a new branch to start work.
git commit -a -m 'quick message'
- Commit changes.
- The -a automatically “adds” changed and deleted files, but not untracked files.
- See commit -a docs.
git push
- Push to the remote repo.
- Normally this would show an error that the branch name doesn’t exist on the remote.
- However, I have a config setting that automatically creates a branch on remote.
- config setting: git config --global push.default current
- See push.default docs.

With Autocorrect

Even if I mistype a command, it will work:

Lean TDD

Sun, 20 Feb 2022 00:00:00 +0000

Preface

Lean TDD is an attempt to reconcile some conflicting aspects of Test Driven Development and Lean Software Development.

I’ve mentioned Lean TDD on the podcast a few times and even tried to do a quick outline at the end of episode 162.

This post is a more complete outline, or at least a first draft.

In audio form

The initial version of this post is also available in audio form as Test & Code, episode 180.

Pinning Application Dependencies with pip-tools compile

Wed, 09 Jun 2021 00:00:00 +0000

pip-tools has more functionality than this, but compile alone is quite useful.

Start with a loose list of dependencies in requirements.in:

typer
rich

The requirements.in file can have things like >= and such if you have some restrictions on your dependencies.

Now install pip-tools:

pip install pip-tools

Then, in create a requirements.txt file with compile:

pip-compile requirements.in

or:

python -m piptools compile requirements.in

The output will be shown on stdout, but also in requirements.txt:

PythonBytes.fm

Thu, 10 Nov 2016 08:49:03 +0000

Michael Kennedy from Talk Python to Me and I have launched a new podcast, called Python Bytes, “Python headlines delivered directly to your earbuds”. It’s a weekly short format podcast. Please check it out.

The first few weeks of a podcast can really make a difference if we can get a bunch of listeners to try it right away. Please consider leaving a review on iTunes. Even if you don’t use iTunes to listen, early reviews can really help with visibility.

Python featured in April issue of PragPub

Wed, 06 Apr 2016 18:04:43 +0000

PragPub April 2016 featuring Python (and me)

PragPub is the digital magazine put out by Pragmatic Bookshelf, Michael Swaine, and Nancy Groth.

I’m especially excited about it because I have two articles featured.
I mostly know Michael from the many years of reading Dr Dobb’s.
And I respect Pragmatic Bookshelf for their work in technical publishing.

So I was thrilled to be asked to contribute.

From the Contents page:

Given-When-Then

Wed, 10 Feb 2016 06:54:35 +0000

Designing your test methods using a simple structure such as given-when-then will help you:

Communicate the purpose of your test more clearly
Focus your thinking while writing the test
Make test writing faster
Make it easier to re-use parts of your test
Highlight the assumptions you are making about the test preconditions
Highlight what outcomes you are expecting and testing against.

In this post I’ll be talking about designing your test cases/test methods using given-when-then.

pytest expect fixture plugin, iteration 1

Tue, 10 Mar 2015 13:28:02 +0000

This is the first iteration that implements ’expect’ as a fixture.

This is really the third attempt at an ’expect()’ implementation that allows multiple failures per test.

First attempt was a general solution that works with any test framework, but with a slightly clunky API. The main problem with it was that it required the test to call a final ‘assert_expectations()’ from the test code. If you forgot to call that function, the failures weren’t reported.
Second attempt was a pytest plugin implementation that eliminated the need for the ‘assert_expectations()’ call in the test because it was called automatically. I wasn’t thrilled with this solution. But it works.
In the solution I’m presenting in this post, I’m moving all of the code into one file and implementing ’expect’ as a pytest fixture.

The end result of all of this is now a plugin called pytest-check

I think there are advantages to having ’expect’ as a fixture.
Let me know what you think.

Test First Programming / Test First Development

Tue, 03 Mar 2015 08:19:09 +0000

Occasionally referred to as “Test First Development”, “Test First Programming” is a beautiful concept that radically changed the way I approach software development.

The ideas of “Test First Programming” and “Test Driven Development” are often muddled together.
However, “Test First” is powerful enough to stand on it’s own.
I think it’s important to present the concepts separately.

“TDD” and many other agile practices build on “Test First”.
This isn’t just about remembering the past.
The lessons learned from “Test First” are still very important.

pytest delayed assert / multiple failure plugin, iteration 1

Thu, 19 Feb 2015 05:17:48 +0000

In Delayed assert / multiple failures per test, I presented a first attempt at writing an expect() function that will allow
a test function to collect multiple failures and not stop execution until the end of the test.

The end result of all of this is now a plugin called pytest-check

There’s one big thing about that method that I don’t like.
I don’t like having to call assert_expectations() within the test.
It would be cool to push that part into a plugin.

Delayed assert / multiple failures per test

Fri, 13 Feb 2015 08:20:14 +0000

The end result of all of this is now a plugin called pytest-check

A test stops execution once it hits a failing assert statement.
That’s kinda the point of an assert statement, though, so that’s not surprising.

However, sometimes it’s useful to continue with the test even with a failing assert.

I’m going to present one method for getting around this restriction, to test multiple things, allow multiple failures per test, and continue execution after a failure.

Why Most Unit Testing is Waste

Fri, 01 Aug 2014 12:55:48 +0000

I don’t rememember how I ran across this article by James O Coplien. However, I was immediately impressed with the thought and experience that went into this paper. Regardless of your viewpoints towards unit tests vs. other types of automated tests, this article is important to read.
If your first reaction to the title is anger, please take a deep breath, try to keep an open mind, and actually READ what Cope has to say. I am going to reserve my own reactions to this to a future post, as I don’t want to color your views before you read it. I am posting the entire article with no changes other than formatting.

My reaction to “Is TDD Dead?”

Sun, 25 May 2014 07:26:48 +0000

Whatever your stance on the merits or pitfalls of Test Driven Development, I think it’s worthwhile and educational to pay attention to a discussion that’s going on lately.

Testing is crucial. But is unit test focused TDD the right path?

I care about the conversation about TDD because I see serious flaws in the conventional understanding of TDD.

Much of the current view of TDD includes:

Units are tested in isolation of the rest of the system.
Unit tests are more important than any other form of testing.
A “unit” is a class or a function. Nothing larger is a “unit”.
If you test more than one class, that’s an integration test.
If you test from the API with all resources, that’s a system test. Let QA deal with that later. Isn’t that exactly where waterfall failed?
You can’t write any production code without a failing test.
You have to write only one test at a time, and it must fail.
Tests have to be fast.
Therefore, they cannot touch hardware, the file system, other services, or database.
Tests should be short.

All of this rubs me the wrong way.
I’ll get to my thoughts later, but my concern about this cemented view of TDD caused me to be very interested in the current talks.

On to the discussion

I came in after the 2nd video, while doing research on Agile and TDD.
I’m not sure if the order matters, but here’s a list of what I know about the discussions.

Mixing pytest fixture scope

Tue, 25 Mar 2014 13:00:31 +0000

Let’s say I’ve got:

a function scope fixture ‘resource_c’
that uses a module scoped fixture ‘fixture_b’
that uses a session scoped fixture ‘fixture_a’

This all works fine.

conftest.py:

import pytest

@pytest.fixture(scope="session")
def resource_a():
    print('\n[setup] resource_a()')
    yield
    print('[teardown] resource_a()')


@pytest.fixture(scope="module")
def resource_b(resource_a):
    print('[setup] resource_b()')
    yield
    print('[teardown] resource_b()')


@pytest.fixture(scope="function")
def resource_c(resource_b):
    print('[setup] resource_c()')
    yield
    print('\n[teardown] resource_c()')

test_alpha.py:

def test_one(resource_c):
    print('In test_one()')

def test_two(resource_c):
    print('In test_two()')

test_beta.py:

def test_three(resource_c):
    print('In test_three()')

def test_four(resource_c):
    print('In test_four()')

This seems reasonable to me.
What do you think will happen?

pytest session scoped fixtures

Tue, 25 Mar 2014 13:00:31 +0000

In pytest fixture scope, I noted that you can specify session scope so that a fixture will only run once per test session and be available across multiple test functions, classes, and modules.

In this post, I’m going to show a simple example so you can see it in action.

Here’s the table from the previous post:

A separate file for fixtures, conftest.py

With function, class, and module scope, it is completely reasonable for the fixture code to be in the same file as the tests.
But now suddenly, with session, that doesn’t make sense anymore.

Using pytest fixtures by naming them

Wed, 05 Feb 2014 06:23:04 +0000

The easiest way to use a fixture is to name it.

We can put the fixture name in the parameter list for each test that needs it:

import pytest

@pytest.fixture()
def before():
    print('\nbefore each test')

def test_1(before):
    print('test_1()')

def test_2(before):
    print('test_2()')

The fixture is going to be called for every test that names the fixture in it’s parameter list.

Output:

$ pytest -s test_fixture.py 
=========== test session starts ============
collected 2 items                          

test_fixture.py 
before each test
test_1()
.
before each test
test_2()
.

============ 2 passed in 0.05s =============

This post is part of a series on pytest fixtures

Modularity - pytest fixtures using other fixtures

Wed, 05 Feb 2014 06:22:11 +0000

Tests can use one or more fixture.

Fixtures themselves can also use one or more fixtures.

I’ll rewrite the example from Using multiple pytest fixtures, but instead of having the tests include all foo, bar, and baz fixtures, I’ll chain them together.

And one more wrinkle, ’test_two’ will only include ‘bar’.

@pytest.fixture(scope="module")
def foo():
    print('\nfoo setup - module fixture')
    yield
    print('foo teardown - module fixture')

@pytest.fixture()
def bar(foo):
    print('bar setup - function fixture')
    yield
    print('bar teardown - function fixture')

@pytest.fixture()
def baz(bar):
    print('baz setup - function fixture')
    yield
    print('baz teardown - function fixture')

def test_one(baz):
    print('in test_one()')

def test_two(bar): # only use bar
    print('in test_two()')

output

Using multiple pytest fixtures

Wed, 05 Feb 2014 06:22:10 +0000

In the examples I’ve used so far in this series , tests only are using at most one named fixture.

You can use more.

Simple example:

import pytest

@pytest.fixture(scope="module")
def foo():
    print('\nfoo setup - module fixture')
    yield
    print('foo teardown - module fixture')

@pytest.fixture()
def bar():
    print('bar setup - function fixture')
    yield
    print('bar teardown - function fixture')

@pytest.fixture()
def baz():
    print('baz setup - function fixture')
    yield
    print('baz teardown - function fixture')

def test_one(foo, bar, baz):
    print('in test_one()')

def test_two(foo, bar, baz):
    print('in test_two()')

$ pytest -s test_multiple.py
================== test session starts ==================
collected 2 items                                       

test_multiple.py 
foo setup - module fixture
bar setup - function fixture
baz setup - function fixture
in test_one()
.baz teardown - function fixture
bar teardown - function fixture
bar setup - function fixture
baz setup - function fixture
in test_two()
.baz teardown - function fixture
bar teardown - function fixture
foo teardown - module fixture

=================== 2 passed in 0.06s ===================

This post is part of a series on pytest fixtures

Parametrizing pytest fixtures with params

Wed, 05 Feb 2014 06:22:09 +0000

An optional parameter to the fixture decorator is params.

For each value in params, the fixture will be called with request.param filled in with that value.
Tests that use the fixture will be called once FOR EACH value in params.

Toy example

An example is in order here.

This first example is a silly one, but does show the mechanics, and the utility of both the -v flag and how well pytest deals with failures of parameterized tests.

pytest fixture scope

Wed, 05 Feb 2014 06:22:08 +0000

Scope controls how often a fixture gets called.

The default is “function”.

Here are the options for scope:

scope	When setup and teardown run
function	(default) Setup before each function, teardown after each function
class	Setup before first test of class, teardown after last test of class
module	Setup/Teardown bracketing tests of a module
package	Setup/Teardown bracketing tests of a package/directory
session	Setup/Teardown at the beginning and end of the entire test session / test run

Since the default scope is “function”, the cheese db example will open and close the db for every test.

pytest fixture return value

Wed, 05 Feb 2014 06:22:07 +0000

In the basic example, the fixture returns None.
It actually doesn’t have a return statement. So like any other function in Python, if you don’t supply a return (or yield) statement, it returns None.

However, you can return anything you want from the fixture function.
If your fixture is setting up some data, or reading a file, or opening a connection to a database, then access to that data or resources is what you ought to return from the fixture.

pytest fixture teardown

Wed, 05 Feb 2014 06:22:07 +0000

In the previous post about return value the ‘cheese_db’ fixture looked like this:

@pytest.fixture()
def cheese_db(request):
    # setup
    print('\n[setup] cheese_db, connect to db')

    # code to connect to your db 
    makeshift_cheese_db = {'Brie': 'No.', 'Camenbert': 'Ah! We have Camenbert, yessir.'}

    # return db to test code
    return makeshift_cheese_db

That’s really not going to work if we have a real database or other resource that we need to possibly, actually disconnect from when we’re done.

For resources where we need some code to happen “when we’re done” with them, we use the teardown section of fixtures.
The “teardown” section is just “anything after a yield”.

Using pytest fixtures with mark.usefixtures

Wed, 05 Feb 2014 06:22:06 +0000

Usefixtures example

Let’s go back to our basic example, but explore the use of usefixtures.

usefixtures is a marker that accepts a list of fixture names as strings, and applies it to something.

You can use it on an individual test. However, it’d be pretty silly as named parameters are easier.

However, this is what it’d look like to mark individual tests:

# test_usefixtures.py
import pytest

@pytest.fixture()
def before():
    print('\nbefore each test')

@pytest.mark.usefixtures("before") 
def test_1():
    ...

@pytest.mark.usefixtures("before") 
def test_2():
    ...

And it also works for test methods:

Using pytest autouse fixtures

Wed, 05 Feb 2014 06:22:05 +0000

Naming a fixture is the most straight-forward way to use fixtures. However, it also requires that we have to add the fixture name to every test that we want to use the fixture.

There are times when we want something to happen before every test, and the test itself doesn’t really need to know about it. For that, we can use autouse.

If you add autouse=True as a parameter to @pytest.fixture(), then all tests that have access to this fixture will use the fixture.

Basic pytest fixtures example

Wed, 05 Feb 2014 06:22:03 +0000

Fixtures hold setup code

Fixtures are a way to separate some code that we want to run before or after a test and put it in a different function than the test function itself.

Let’s say we have a couple of tests with common setup code:

def test_1():
    # setup code running before the test
    print('\nbefore each test')
    # actual test code
    print('test_1()')

def test_2():
    # setup code running before the test
    print('\nbefore each test')
    # actual test code
    print('test_2()')

We could use xunit fixtures, but we’re not going to

If we want to use xunit fixtures, we could create a setup function like:

pytest xUnit style fixtures

Sat, 28 Dec 2013 10:08:14 +0000

I’m going to cover the syntax for pytest support for xUnit style fixtures.
Then I’ll give a more reasonable and typical example, using just one set of fixture functions.
And then address the issue of having tests mixed in a file. Some that need the resource, and some that don’t.

Depending on what scope you want your fixtures, you define setup/teardown pairs.

Module (setup_module/teardown_module)
- Sets things up once for the module, teardown after everything.
Function (setup_function/teardown_function)
- Wraps every test function with calls.
- Gets called multiple times, once for each function
Class (setup_class/teardown_class)
- Like module level, but for classes, once for a class.
Method (setup_method/teardown_method)
- Like function level, but for classes.
- Gets called multiple times, once for each test method in a class

Unless you really need xUnit fixtures, I recommend completely ignoring this post.
It’s way better to move on and use only native pytest fixtures.

pytest fixtures nuts and bolts

Mon, 18 Nov 2013 01:54:23 +0000

Dealing with fixtures is one of the areas where pytest really shines.
This is rather an incredible understatement.

The xunit style of test fixtures that is used in both unittest and nose is of course supported with with pytest. And pytest rocks at this.

But there is another way to deal with fixtures. It’s to think of fixtures as a set of resources that need to be set up before a test starts, and cleaned up after. Test functions, methods, classes, name which fixtures they need. This way, fixtures aren’t set up for tests that don’t need them.

The power of “Thank You”

Tue, 01 Oct 2013 23:39:59 +0000

Fozzie: Nobody reads those names anyway, do they?
Kermit: Sure. They all have families.

– The Great Muppet Caper

Many projects have release notes that include the names of people that contributed to the release.

Who reads these names?
Well, at the very least, the people in that list read the names.

If your project doesn’t do this, I think it should.
My name was listed in a release notice today.
I’ll share the details, and try to point out why saying thanks to contributors is a good idea.

tip: dictionary get() works like getattr

Wed, 21 Aug 2013 19:14:26 +0000

You can’t use getattr() to look stuff up in a dictionary.
But the ‘default’ feature of getattr() is so useful.
What’s the dict way to do the same thing?

This is one of those posts that I’m writing because I keep having to look it up.
So if I write it, I’ll remember it. Hopefully.

getattr

I’ve been using the ‘default’ parameter to getattr for some time, and it’s super handy.
This is handy in lots of places, and avoids having to wrap things in try/except blocks.

I’m annoyed with Python’s ternary operator

Tue, 02 Jul 2013 16:14:23 +0000

The ternary operator is a way to concisely say:
“If test, then a, else b“,
with the value of the statement being the value of a or b.

language	how to say it
C	test ? a : b
C++	test ? a : b
javascript	test ? a : b
Perl (not perl 6)	test ? a : b
PHP	test ? a : b
Ruby	test ? a : b
Did I forget some language?	probably
Python	a if test else b (Why??)

Why??

Ok. Now that I’ve written this post, I’ll remember it.

pytest support for unittest style fixtures

Wed, 26 Jun 2013 21:07:11 +0000

unittest fixtures behave the same regardless if you run them from python -m unittest or pytest.

There used to be more of a story here.

Way back in 2013 with pytest 2.3.5 (when this post was originally written) there was an issue that the behavior of whether or not to run the teardown for unittest fixtures if the setup failed was different.

However, that’s been fixed A LONG TIME AGO.

Run a single test class with unittest and pytest

Wed, 19 Jun 2013 14:10:19 +0000

I’ve got the test code from my unittest fixture syntax and flow reference, and I want to try to run one class, say TestSkip from unittest and pytest to compare the the control flow.

Therefore, I need for each framework:

The option to make it as quiet as possible
- -q for both unittest and pytest
The option to turn off output capture
- -s works for pytest, not needed for unittest
The way to call an individual class
- details below
- note that moduleName == fileName (but without the extension)

unittest

Specify moduleName.className, like so:

What happens when unittest fixtures fail

Mon, 17 Jun 2013 16:50:05 +0000

In unittest fixture syntax and flow reference, I only presented fixture methods and functions that threw no exceptions.
However, in real production code, it is entirely possible for something to go wrong when setting up test fixtures.

This post is simply do demonstrate exactly what happens to the flow of your test code when an exception is thrown in a fixture function.

And, while I’m at it, I may as well demo the normal control flow when a test fails, asserts, or throws an exception.

unittest fixture syntax and flow reference

Sun, 16 Jun 2013 00:15:33 +0000

This post contains examples of how unittest test fixture functions and methods are written, and in what order they run. It may seem like a long post, but it’s mostly code examples and example output.

I want this to be a useful reference for both the syntax and flow of unittest fixtures.

Intro: Software Test Fixtures

The term test fixtures really means two things.
Test fixtures are the resources and initial conditions that a test needs to operate correctly and independently from other tests.
The phrase has also grown to mean the functions and methods that are used to do that resource and environment handling.

Complete coverage testing from the bottom of the pyramid up is a bad idea

Tue, 21 May 2013 14:14:49 +0000

or Complete coverage testing
or More is Better testing
or How not to test, part 1

The setup

For the sake of this post, let’s say I’ve got a Python package that needs testing.

It’s written completely in Python
It has a specification fully describing the API
The specification is so complete that it also covers behaviors and side effects
The API is the only interface this program exposes
It was written by us
It was written recently
It only uses base Python

Therefore:

pytest debug print logging in real time

Thu, 04 Apr 2013 02:23:18 +0000

There are many circumstances where it’s really great to display the print statements and logging from a test while a test is running, and not wait until the end.

Printing and logging in test code

Before you pipe in with “unit tests should be fast”, I’ll just remind you that pytest can be used for system tests, performance tests, and other long running tests, and can be used to test both software and hardware.

Python regex Search and Replace Examples

Fri, 08 Feb 2013 00:00:00 +0000

Search and replace is such a common task that it should be a tool that’s in every command line script author’s toolbox.
There are probably endless solutions to the problem.
I’ve put together my standard methods for tackling the problem.
I’ll also show similar Perl versions, mainly for comparisons.

use models

In most of the following discussion, I’m just replacing ‘foo’ with ‘bar’.
However ‘foo’ can be ANY regular expression.

Perl regex Search and Replace Examples

Thu, 07 Feb 2013 00:00:00 +0000

Search and replace is such a common task that it should be a tool that’s in every command line script author’s toolbox.
There are probably endless solutions to the problem.
I’ve put together my standard methods for tackling the problem, with Perl. You can also use Python, of course, as well as other tools like sed.

Use Models

In most of the following discussion, I’m just replacing ‘foo’ with ‘bar’.
However ‘foo’ can be ANY regular expression.

Don't use nose

Tue, 29 Jan 2013 15:51:12 +0000

As of 2025, nose hasn’t been updated for about 10 years.

I don’t recommend using it.
I recommend trying out pytest. :)

A note on the nose docs page recommends using a different project, such pytest or unittest:

Note to Users

Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using Nose2, py.test, or just plain unittest/unittest2.

Running doctest from pytest

Tue, 15 Jan 2013 13:39:34 +0000

You can run some doctests from pytest, according to the documentation.
However, it can be a bit fiddly.

With my examples of putting doctests in text files, if I just try running:

$ pytest test_unnecessary_math.txt

I get the error:

... ModuleNotFoundError: No module named 'unnecessary_math'

It doesn’t seem to like the line “from unnecessary_math import multiply” from the .txt file, even thought he file unnecessary_math is in the same directory.

However, if I throw that same like into a conftest.py file, it seems to work:

Running unittest from pytest

Tue, 15 Jan 2013 13:38:34 +0000

To show how pytest handles unittests, here’s a sample run of pytest on the simple unittests I wrote in the unittest introduction:

$ pytest test_um_unittest.py 
======================== test session starts =========================
collected 2 items                                                    

test_um_unittest.py ..                                         [100%]

========================= 2 passed in 0.04s ==========================

$ pytest -v test_um_unittest.py
======================== test session starts =========================
collected 2 items                                                    

test_um_unittest.py::TestUM::test_numbers_3_4 PASSED           [ 50%]
test_um_unittest.py::TestUM::test_strings_a_3 PASSED           [100%]

========================= 2 passed in 0.05s ==========================

As you can see, I didn’t provide any extra options, pytest finds unittests automatically.

pytest introduction

Tue, 15 Jan 2013 13:36:34 +0000

I think of pytest as the run-anything, no boilerplate, no required api, use-this-unless-you-have-a-reason-not-to test framework.
This is really where testing gets fun.
As with previous intro’s on this site, I’ll run through an overview, then a simple example, then throw pytest at my markdown.py project.
I’ll also cover fixtures, test discovery, and running unittests with pytest.

No boilerplate, no required api

The doctest and unittest both come with Python.
They are pretty powerful on their own, and I think you should at least know about those frameworks, and learn how to run them at least on some toy examples, as it gives you a mental framework to view other test frameworks.

Confession … I still use perl on the command line

Wed, 09 Jan 2013 00:00:04 +0000

I have a confession to make.

I still use Perl. Regularly. But mostly as a command line tool. Is that a reason? or an excuse?

When I started using Python regularly, I tried to replace my Perl usage.
Nothing against Perl, I just wanted to force myself to use Python to aid in my learning of the language.

I still have quite a few Perl habits that are hard to break.

unittest introduction

Fri, 04 Jan 2013 05:22:18 +0000

The unittest test framework is python’s xUnit style framework.
It is a standard module that you already have if you’ve got python version 2.1 or greater.
In this post, I’ll cover the basics of how to create and run a simple test using unittest.
Then I’ll show how I’m using it to test markdown.py.

Overview of unittest

The unittest module used to be called PyUnit, due to it’s legacy as a xUnit style framework.
It works much the same as the other styles of xUnit, and if you’re familiar with unit testing in other languages, this framework (or derived versions), may be the most comfortable for you.

doctest introduction

Tue, 11 Dec 2012 09:16:43 +0000

The doctest test framework is a Python module that comes prepackaged with Python. This post covers the basics of how to put doctests in your code, and outside of your code in a separate file.

We start with a simple working example using a silly script called unnecessary_math.py. Then we go on to show how I’m using doctest to test markdown.py.

conceptual model of Python doctest

This is from python.org:

The doctest module searches for pieces of text that look like interactive Python sessions,
and then executes those sessions to verify that they work exactly as shown.

Software API/CLI interface adapters

Tue, 27 Nov 2012 14:07:19 +0000

While writing software, we are faced with lots and lots of interfaces.
The public interface for some tool or module or package or whatever is usually referred to as the API, the CLI, or simply the user interface.
In this post, when considering an interface, I am specifically referring to APIs and CLIs.

Sometimes, we find a software component that does exactly what we want, but the interface is not what we want.
That’s where software interface adapters come to the rescue.
Adapters are helpful in many stages of the design and development of just about anything.

Stub for markdown.py

Thu, 25 Oct 2012 16:32:15 +0000

To explore the concepts of functional testing using python and python testing frameworks, I’m building a project to test, markdown.py on github.

In this post, I’m discussing the stub implementation that I will use to set up the testing frameworks.

I’ve got my markdown.py requirements written.
An initial set, at least. Enough to get me started.

I want to move on to explore testing frameworks and testing strategy.

But to do that, it will be helpful to have something to test. So I’m going to write a stub for my script. Something that has the right name and interface. I can use it just as I will use the completed script. It just doesn’t work yet.

Markdown requirements

Thu, 25 Oct 2012 12:00:16 +0000

I’ve decided to write my own Markdown script,
possibly for dubious reasons.

I’m getting antsy to code.

But before I get started on the testing and implementation, I want to:

write the requirements
write a simple stub implementation
write a testing strategy
explore test frameworks

Then, FINALLY, I can start testing and implementing.

Let’s take a look at the requirements.

Requirements for Markdown

Written in Python
Use only Python standard library packages
All contained in one python file
Implement enough of the original Markdown functionality to be useful

That’s it for now.

Why Markdown

Wed, 17 Oct 2012 00:00:00 +0000

Markdown has very little to do with python testing.
But I need a project to test, so I’m writing my own Markdown script.
This is a brief introduction to Markdown from my perspective.

Writing HTML sucks. Use Markdown.

HTML is obviously pretty helpful and critical for the web.
One goal for HTML was that humans could reasonably easily read, write, and edit it.
And that kinda works. Sometimes.
But it’s not fun to read or write HTML. Actually, writing stuff in HTML by hand sucks.

posts on PythonTest

Explore Python dependencies with `pipdeptree` and `uv pip tree`

pipdeptree

usage

Announcing the Lean TDD book

Polite lazy imports for Python package maintainers

Previously - lazy importing other packages

Python lazy imports you can use today

Installing Python 3.14 on Mac or Windows

Testing against Python 3.14

Installing Python 3.14

Installing with uv

pytest-check 2.6.0 release

The problem

Timeline of Selected Software Events

Python People podcast now at pythontest.com/pythonpeople

Test and Code Archive is now available

pytest fixtures nuts and bolts - revisited

Time Machine back to 2012

New look

New analytics

Unravelling t-strings with pytest

Testing some tidbits with pytest

Finding the top pytest plugins

Grab data

Parse

Added on 26-Aug:

pytest 8 is here

Version Compatibility

Features and Improvements

Improved Diffs

Testing argparse Applications

pytest slow order

@pytest.mark.slow

Upgrading to Python 3.12 and my battle with virtualenv cache

Sharing is Caring - Sharing pytest Fixtures - PyCascades 2023

pytest tips and tricks

Fixing Circular Imports in Python with Protocol

Testing with Python 3.12

Note about alpha releases of Python

Talk - Sharing is Caring - pytest fixture edition

Sharing is Caring, pytest fixture edition

Current Git CLI workflow

Workflow

Commands

With Autocorrect

Lean TDD

Preface

In audio form

Pinning Application Dependencies with pip-tools compile

PythonBytes.fm

Python featured in April issue of PragPub

Given-When-Then

pytest expect fixture plugin, iteration 1

Test First Programming / Test First Development

pytest delayed assert / multiple failure plugin, iteration 1

Delayed assert / multiple failures per test

Why Most Unit Testing is Waste

My reaction to “Is TDD Dead?”

Testing is crucial. But is unit test focused TDD the right path?

On to the discussion

Mixing pytest fixture scope

pytest session scoped fixtures

A separate file for fixtures, conftest.py

Using pytest fixtures by naming them

Modularity - pytest fixtures using other fixtures

Using multiple pytest fixtures

Parametrizing pytest fixtures with params

Toy example

pytest fixture scope

pytest fixture return value

pytest fixture teardown

Using pytest fixtures with mark.usefixtures

Usefixtures example

Using pytest autouse fixtures

Basic pytest fixtures example

Fixtures hold setup code

We could use xunit fixtures, but we’re not going to

pytest xUnit style fixtures

pytest fixtures nuts and bolts