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.

[alyssadai]

Since there's already some natural differentiation between the test_cli_*.py tests (ones that use the CLIRunner) and test_*util.py tests (ones that don't use the CLIRunner), I'll attempt to address this by refactoring the tests into integration and unit subdirectories for more top-level organization. This hopefully will also give us a bit more flexibility than relying on string matching pytest markers.