Test & Code

Markdown reports as either text or markdown tables.
Two fun plugins discussed.

Links:

• pytest-md-report
• pytest-md
• Top pytest Plugins

This episode is a replay of a 2021 interview I did with Michael Foord.
We lost Michael in January, and I'd like to revisit this interview as a tribute. 

Michael Foord was a pivotal figure in the Python community and the creator of the mock library that's now unittest.mock. 
But he did so much more as well. 
His contributions continue to resonate within the developer community. 
This interview is just a small peek at his influence. 

In this episode

• Introduction to Michael Foord
• The Mock Library Origins
• Mocking and Testing Philosophy
• Career Path and Consulting
• Understanding Mocking
• The Power of Patch
• Testing Strategies and Design
• Mocking External Dependencies
• Teaching Testing and Mocking

python.org has put up an "In memoriam" page for Michael Foord, and many people have shared stories and memories.

Links:

• In memoriam: Michael Foord 1974-2025
• 30 best practices for software development and testing

pytest-mock is currently the #3 pytest plugin. 
pytest-mock is a wrapper around unittest.mock.

In this episode:

• Why the pytest-mock plugin is awesome
• What is mocking, patching, and monkey patching
• What, if any, is the difference between mock, fake, spy, stub. 
• Why we might need these in testing
• Some history of mock in Python and how mock became unittest.mock
• From unittest.mock
  • patch.object
  • patch.object with autospec
  • using these as context managers
• pytest-mock:
  • The mocker fixture 
  • Cleanup in teardown
  • Using mocker.patch, mocker.spy, and mocker.stub
  • Why it's awesome and why you might want to use it over straight unittest.mock

Links:

• top pytest plugins list
• pytest-mock documentation
• unittest.mock
• Podcast episode discussing unittest.mock with Michael Foord
• monkeypatch

pytest-cov is a pytest plugin that helps produce coverage reports using Coverage.py.

In this episode, we'll discuss:

• what Coverage.py is
• why you should measure code coverage on both your source and test code
• what pytest-cov is
• extra features pytest-cov gives you over and above coverage.py
• and generally why using both is awesome

Links:

• coverage.py
• pytest-cov
• how to set up context reports
• Top pytest Plugins

Errata:

• I mentioned that Coverage has the ability to show context (which line is covered by which test) for the past year or so.
  • However, that feature was released in Oct 2018. coverage 5.0 alpha 
  • That's over 6 years. Oops. Sorry Ned.

This episode kicks off a series on pytest plugins.

In this episode:

• Introduction to pytest plugins
• The pytest.org pytest plugin list
• Finding pytest related packages on PyPI
• The Top pytest plugins list on pythontest.com
• Exploring popular plugins
• Learning from plugin examples

Links:

• Top pytest plugins list
• pytest.org plugin list
• Top PyPI Packages
• And links to plugins mentioned in the show can be found at pythontest.com/top-pytest-plugins

Taking notes well can help to listen better, remember things, show respect, be more accountable, free up mind space to solve problems.

This episode discusses

• the benefits of writing things down
• preparing for a meeting
• taking notes in meetings
• reviewing notes for action items, todo items, things to follow up on, etc.
• taking notes to allow for better focus
• writing well structured emails
• writing blog posts and books

In this episode we're talking about importing part of a package into another part of the same package.

We'll look at: `from . import module` and `from .module import something`

and also:  `import package` to access the external API from with the package.

Why would we use `import package` if `from . import api` would work fine?

We've got some code we want to test, and some tests.
The tests need to be able to import the code under test, or at least the API to it, in order to run tests against it.
How do we do that? How do we set things up so that our tests can import our code?

In this episode, we discuss two options:

• Installing the code under test as a pip installable package with `pip install -e /path/to/local/package`.
• Using the pythonpath pytest setting.

PyCon US is just around the corner.  I've asked Rob Ludwick to come on the show to discuss how to get the most out of your PyCon experience. There's a lot to do. A lot of activities to juggle, including actual juggling, which is where we start the conversation.

Even if you never get a chance to go to PyCon, I hope this interview helps you get a feel for the welcoming aspect of the Python community.

I recorded this interview as an episode for one of my other podcasts, Python People. But I think it's got some great pre-conference advice, so I'm sharing it here on Python Test as well.

We talk about: 
- Juggling at PyCon
- How to get the most out of PyCon
    - Watching talks
    - Hallway track
    - Open spaces
    - Lightening talks
    - Expo hall / vendor space
    - Poster sessions
    - Job fair
    - A welcoming community
    - Tutorials 
    - Sprints
    - But mostly about the people of Python and PyCon.

"Python enables smart people to work faster" - Rob Ludwick

I'm starting a SaaS project using Django, and there are tons of decisions right out of the gate.
To help me navigate these decisions, I've brought on Cory Zue.   
Cory is the creator of SaaS Pegasus, and has tons of experience with Django.

Some of the topics discussed:

• Building Django applications
• SaaS Pegasus
• placecard.me
• What boilerplate projects are
• Django cookiecutter
• Cookiecutter
• Which database to use, probably PostgreSQL
• Authentication choises, probably Allauth
• Docker, Docker for development, Docker for deployment
• Deployment targets / hosting services. Render, Heroku, Fly.io, for PaaS options.
• Front end frameworks. Bootstrap, Tailwind, DaisyUI, TailwindUI
• HTMX vs React vs straight Django templates
• Rockets
• Font Awesome
• and of course, SaaS Pegasus