Does it make sense to define compat bounds in the test/Project.toml?

General Usage
1

The question is in the title

2

If you refer in test/Project.toml to the main package like this:

[sources]
MyPackage = {path = ".."}

you inherit the compat bounds of the main Project.toml file.

Only if you use test-only dependencies that might change their api, then include compat bounds for these dependencies in test/Project.toml.

Easy to forget updating these, though.

3

Thank you. Still: to my understanding, tests are normally running in a separate clean environment anyway. The versions of the downstream dependencies of MyPackage for testing must be resolved according to compat bounds in its Project.toml, whether I refer to it explicitly via MyPackage = {path = ".."} or not. The versions of test-specific packages will be resolved to the max available version. If I don’t want to put an upper limit on any of them, what’s the purpose of defining compat bounds?

4

You don’t have to, but that makes it more likely that your tests will break in the near future. Putting compat bounds on them makes it clear to the user of the package which version are expected to work.

5

If you don’t mind the risk that breaking changes in test-only dependencies breaks your tests, feel free to ignore compat bounds. If you know that some higher version breaks your tests and you can’t easily fix it, then compat bounds obviously are very useful.

6

Actually it’s what the tests are for. I’ll get message on CI failure, and look exactly into the issue.

7

Is there a way to tell dependabot to not make PRs to add compat to test/Project.toml?