Migrate to pytest, add Github action for test suite

[mathiasertl]

• Move the test suite to pytest.
• Add GitHub workflow for the test suite.
• Add a Docker image that can be used for testing.
• Test on Python 3.13.
• Move dev-dependencies to uv.

[mathiasertl]

@danni @kislyuk I would appreciate a reviews.

[mathiasertl]

PS: Branch that adds strict typehints is ready after this one ;-).

[kislyuk]

Thanks, I'm working on this in the next couple of days.

[kislyuk]

@mathiasertl this PR is very difficult to review because it's massive. Can you please split it into fewer more manageable PRs?

[kislyuk]

@mathiasertl let's hold off on this PR. It should be done much more incrementally, and I think some of them (such as the use of pytest and Docker) need to be much more deliberately justified as they don't seem relevant to the core functions of the package itself. I am also working on some changes that will conflict with these.

[mathiasertl]

Hi,

Fair point, I'll move some of the unrelated stuff to a separate PR.

Docker: it's just an additional file to run the test suite, it's not used anywhere else. I wrote it because for unknown reasons, softhsm access in GitHub doesn't work with the package from APT (that's why it's compiled just like it was in TravisCI, see notes there). Since I already had it, I thought I might commit it just as well. If you want, I can remove it of course?

Pytest: it's what everyone uses, for good reason. It's almost impossible to do this incrementally without code duplication. If you ignore whitespace, you'll see that the test code itself has not changed at all. If you insist, I can make incremental PRs for that?

Kr, Mat

[kislyuk]

OK, thanks for elaborating - let's keep the Dockerfile in a separate PR for now until I can understand the issue better.

I am not completely opposed to Pytest but I find the argument that "everyone uses it and therefore we must" extremely tiresome. I think there should be a high bar to switching away from solutions provided by the standard library (unittest) to external ones. I like pytest but I think its fixture autoloading process is poorly designed, and I also like unittest and its inheritance/class based test case organization just as well and I don't see a specific reason to switch this project to pytest so far. If such reasons are identified, then at minimum, we should take the incremental approach of first switching to pytest and using its unittest compatibility layer, and only then switching tests to the pytest style where needed.

[kislyuk]

I just looked more carefully at the PR and yeah, I'm not on board with using conftest.py and the fixtures in it. That's the poorly designed part of pytest that I was talking about. Let's keep this type of setup in unittest setup methods for legibility.