pytest-aoc

This pytest plugin downloads puzzle inputs for Advent of Code and synthesizes fixtures that you can use in your tests.

Does this DDoS the adventofcode.com website?

This plugin tries pretty hard to not hit the adventofcode.com website unless absolutely necessary. When the test session starts, the puzzle inputs that should be available are calculated based on the system clock. For every input that should be available (after 05:00:00 GMT), if no corresponding text file is found on disk, it gets downloaded and saved, if the HTTP status code is 200 OK.

The personal downloaded puzzle inputs should be committed to source control, so that pytest doesn't need to hit the adventofcode.com API to run the tests in another environment.

New in version 1.22.0: the code also sleeps (2.5 seconds by default) after hitting the server. This can be disabled if you have leaderboard aspirations, but really, do you have time to be practising TDD in that case?

Installing and configuring

Installing is easy: python -m pip install pytest-aoc. Next you will need to configure two things: for which event (year) the plugin should download inputs, and a valid session cookie. These are normally valid for about a month or so.

To set the year, put it in setup.cfg:

[tool:pytest]
aoc_year = 2018

Better yet, ditch setup.cfg and use pyproject.toml:

[tool.pytest.ini_options]
aoc_year = 2023

Then, put a valid session ID in a file named .cookie and also name this file in your .gitignore.

With these two things in place, when running pytest, this plugin will download any missing inputs, and generate pytest fixtures that you can use in your test functions, see 'Using' and 'Fixtures', below.

Using

With this plugin properly configured, you can write tests like this:

def test_01a(day01_numbers):
    assert sum(day01_numbers) == 123

Here, the parameter day01_numbers is a fixture that contains the numbers on each line in the file input/day01.txt.

Fixtures

These fixtures are synthesized for each available day. They're not executed until you ask for them in a test.

Command-line and configuration options

You can pass the options from the command line or set them in setup.cfg. The command line takes precedence.

Developing / testing

Set environment variables using . .envrc or by automatically loading them using direnv allow.

Create a virtualenv named env and install an editable version of this package with all extra development dependencies:

python -m venv env
python -m pip install -U -e .[dev,test]

Run tests directly, to test against the current Python, or via tox to test against multiple Python versions:

python -m pytest
python -m tox run

Releasing

The procedure goes like this:

• Set a git tag to let setuptools-scm derive a version from it
• Use build to package up the sdist and the wheel
• Upload sdist and wheel to Pypi using twine
• Create a release on Gitlab using gitlab-cli

Tagging the release commit

(Optional) Tag the release version (or it will be a dev release on the next version as derived by setuptools-scm) where x.y.z is the version:

git tag -a x.y.z

...or even use bash history to refer to the third argument (:3) of the current command (!#):

git tag -a x.y.z -m !#:3

But: prefer to write the release notes in here, so don't actually use -m for non-rc releases.

Check that the version is actually sane:

python -m setuptools_scm

Build the package files

Bake an sdist and a wheel into a clean dist directory:

rm -f dist/*
python -m build

Upload to PyPI

Upload the goods to PyPI:

python -m twine upload dist/*

(I tried the --sign option once, got an email from PyPI saying GPG signatures are unsupported on PyPI, and am now reconsidering some very recent life choices. Dammit, I went decades without needing a PGP key, could I not have continued to do without?)

Create release on Gitlab

Upload the goods to Gitlab, where again x.y.z is the version:

git push gitlab main --tags
glab release create x.y.z dist/*.{tar.gz,whl}