Test & Code

Iterative processes that include writing test code and production code together, such as TDD, help make coding fun. 

All of us that care about developing quality code with the help of testing can learn from each other, regardless of programming language.

Today we step outside our normal Python comfort zone and talk with Gio about TDD in Swift.

Gio Lodi, author of TDD in Swift, joins the show to discuss Test Driven Development, software workflows, bottom up vs top down, rapid feedback, developer vs customer facing tests, and more.

Links:

• TDD in Swift with SwiftUI and Combine
• mokacoding - Gio's blog
• XCTest
• Software Design: Tidy First? - Kent Beck on Substack

pre-commit started as a framework for running linters and code formatters during git actions via git hooks. It's grown and expanded and now supports an extensive list of languages and actions and manual running of actions. But even at it's core, it's great for letting computers nitpick about whitespace and formatting, so that code reviews can focus on architecture and design.

Anthony Sottile discusses pre-commit, for using locally by developers, and pre-commit.ci, which can run actions during merge requests.

"Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks." - pre-commit.com

"Developers spend a fair chunk of time during their development flow fixing relatively trivial problems in their code. pre-commit.ci both enforces that these issues are discovered, which is opt in for each developer workflow via pre-commit, but also fixes the issues automatically, letting developers focus their time on more valuable problems." - A user of pre-commit.ci

Links:

• pre-commit
• pre-commit supported hooks
• pre-commit.ci

Flake8 is a command-line tool for linting Python projects. 
 By default, it includes lint checks provided Pyflakes, pycodestyle, and McCabe
 It's also a platform, and allows plugins to extend the checks.
 Flake8 will run third-party extensions if they are found and installed.

But what does all of that mean?

Anthony Sottile is a maintainer of flake8 and has kindly offered to explain it to us.

Links:

• Flake8: Your Tool For Style Guide Enforcement
• pyflakes
• pycodestyle
• mccabe
• pyflakes/messages.py
• flake8 Error / Violation Codes
• wemake-python-styleguide
• flake8-typing-imports
• tox automation project
• Nox
• pre-commit

Tim Ottinger has four questions that work great in many situations, from doing homework, to cooking, to writing code, to entire software projects.

They are actually awesome questions to ask during a software project.

We discuss the questions, where they came from, and look at some uses in software.

The questions:

1. What is it that needs to be done?
2. What do we need in order to do it?
3. Where can we get what we need?
4. How can we tell if we’re doing it right?

Bonus question that can be swapped out for #1:

1. What's the most important thing that it doesn't do yet?

Links:

• The Four Questions

You need tests for your web app. And it has a database. What do you do with the database during testing? Should you use the real thing? or mock it? Jeff Triplett says don't mock it.

In this episode, we talk with Jeff about testing web applications, specifically Django apps, and of course talk about the downsides of database mocking.

Links:

• "🤔 In ~12 years, I have never seen a case where mocking a database was a good idea. ..." 
• Django News
• Moto
• Test & Code 103: Django - Lacey Williams Henschel
• Model Bakery: Smart fixtures for better tests 
• Faker

Playwright is an end to end automated testing framework for web apps with Python support and even a pytest plugin.

Links:

• Playwright for Python
• Why Playwright?
• playwright-pytest

I always learn a lot when I talk to Brett, and this episode is no exception.
 We talk about the packaging workflow, tools, changes, pyproject.toml, flit, setuptools, and so much more.
 I hope you learn as much as I did in this great discussion.

Links:

• pytest-srcpaths
• Python Packaging User Guide
• pypa/packaging: Core utilities for Python packages
• flit and requires-python
• Extending and Embedding the Python Interpreter — Python 3.9.2 documentation
• Flit
• setuptools
• PEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org
• PEP 517 -- A build-system independent format for source trees | Python.org
• Flit editable installs with --symlink or --pth-file
• PEP 440 -- Version Identification and Dependency Specification | Python.org
• Specifying requires-python with flit
• wheel
• Universal 1 binary
• Universal 2 binary
• Cython: C-Extensions for Python
• CFFI
• pybind11: Seamless operability between C++11 and Python
• Conda
• conda environments
• conda-forge
• VaultsOfParnassus

Adventure, or Colossal Cave Adventure, was written between 1975 and 1977 in Fortran. Brandon Rhodes ported it to Python 3, initial release in 2011, and still maintains it. We talk to Brandon about this wonderful game.

What's happening is that I'm playing adventure, which you can pip install thanks to Brandon Rohdes. Adventure is a faithful port to Python 3 from the original 1977 FORTRAN code by Crowther and Woods that lets you explore Colossal Cave, where others have found fortunes in treasure and gold, ...

In this episode, we talk with Brandon Rhodes about this marvelous game.

Links:

• adventure · PyPI
• python-adventure: Original Colossal Caves adventure game, but in Python 3
• Brandon Rhodes Personal Site
• Python Design Patterns
• pyephem: Scientific-grade astronomy routines for Python
• python-skyfield: Elegant astronomy for Python
• Adventure in Python 3 - announcement blog post from 2012
• NetHack
• FTL: Faster Than Light
• PEP 517 -- A build-system independent format for source trees | Python.org

Coming up with a testing strategy doesn't have to be stressful. Prioritizing features to test, and generating test cases for each feature can be fairly quick and painless. This episode covers a strategy for both that can be applied to many types of software.

Corey Quinn is the Chief Cloud Economist at The Duckbill Group. He's also a podcaster and writes a newsletter. And he also automates things with Python. But he doesn't write tests. Let's find out why.

Reason for the interview. Rough summary of a twitter conversation:

• Corey: What podcasts should I try to get an invite onto?
• ToonArmyCaptain: Python Bytes, Test & Code, Talk Python
• Corey: But... I don't test my code, "crappy Python" is all I write, and I'd feel like a giant imposter. So yeah, I'd be game. link
• So here we are. 

This diagram is referenced in the show, the Last Week In AWS Newsletter Production Pipeline.

Special Guest: Corey Quinn.

Links:

• Last Week in AWS