Refactor the tests to be clearer and better differentiated between integration and unit

[surchs]

We now have a lot of example test files with very minimal differences between them. That is because we are running most of our tests as integration tests (e.g. run through the entire app and looking at it from the outside). That makes sense to make sure that certain input files lead to certain behaviour of the entire app. I don't think this makes as much sense for asserting that very specific error messages are raised or warnings given. For this, we could just use a unit test of the function that does the raising or warning.

In return, we might be able to condense our examples to a couple of "valid" ones with some allowed variability, a couple of ones that should warn, and a couple that should fail outright. it will also make understanding the tests easier and be clearer to reason about if and when these tests fail.

Other potential options:

• order the tests in some semantically meaningful way / split them into more test modules so we know where to look for and where to add similar tests
• set up pytest markers for e.g., integration vs. unit tests following https://docs.pytest.org/en/7.1.x/how-to/mark.html

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days.
We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days.
We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.