# Does it make sense to define compat bounds in the test/Project.toml?
**URL:** https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466
**Category:** General Usage
**Tags:** testing
**Created:** [July 25, 2026, 1:21pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466 "2026-07-25T13:21:44Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [July 25, 2026, 1:21pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/1 "2026-07-25T13:21:44Z")
The question is in the title
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 25, 2026, 1:41pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/2 "2026-07-25T13:41:45Z")
If you refer in `test/Project.toml` to the main package like this:
```julia-auto
[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.
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [July 25, 2026, 2:08pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/3 "2026-07-25T14:08:28Z")
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?
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 25, 2026, 2:24pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/4 "2026-07-25T14:24:26Z")
> [@Eben60](#):
>
> If I don’t want to put an upper limit on any of them, what’s the purpose of defining compat bounds?
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.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [July 25, 2026, 2:25pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/5 "2026-07-25T14:25:24Z")
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.
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [July 25, 2026, 2:29pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/6 "2026-07-25T14:29:02Z")
> [@GunnarFarneback](#):
>
> If you don’t mind the risk that breaking changes in test-only dependencies breaks your tests
Actually it’s what the tests are for. I’ll get message on CI failure, and look exactly into the issue.
---
### Author:  [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [July 25, 2026, 2:31pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/7 "2026-07-25T14:31:14Z")
Is there a way to tell dependabot to not make PRs to add compat to test/Project.toml?
---
### Author:  [@penelopeysm](https://discourse.julialang.org/u/penelopeysm)
#### Post date: [July 25, 2026, 5:35pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/8 "2026-07-25T17:35:01Z")
I think there are more uses to compat bounds in `test/Project.toml` than might first meet the eye. The following are things that I have encountered as a developer on one of Julia’s larger libraries.
Broadly speaking, the logic IMO is the same as in normal `Project.toml` compat bounds. If your tests need a specific package version to run, or if the tested behaviour only works with a specific package version, then put in a compat entry.
To give a motivating example: let’s say that you are developing a package `MyPkg`, which pulls in a dependency `MyDep`. Now, `MyDep` has two versions, v1 and v2, that are broadly in use in the Julia ecosystem.
You can make your package compatible with both versions of `MyDep` so as to not force your users to be locked into either one. But when it comes to testing, you only want to test the behaviour of your package with the newer version `MyDep@2`. (One could argue that you should do downgrade tests with `MyDep@1` as well, but pragmatically speaking CI resources are limited, and nobody out there does downgrade tests on all their deps.)
In such a case it is certainly valuable to put a compat bound on `MyDep` in `test/Project.toml`. Otherwise, it’s very easy to accidentally pull in a different test dependency which pulls in `MyDep@1` and makes your tests fail, and you have to trawl through the CI logs and/or Manifest to figure out what happened.
This is not a hypothetical scenario: generally Julia packages are quite fast to update compat but I can list off the top of my head transition periods with ForwardDiff v0 → v1, JSON v0 → v1, PrettyTables v2 → v3, and various SciML packages. (That’s not meant as a criticism of anyone; it’s just Open Source Life.)
Indeed the two different versions need not even be semver-incompatible. Different semver-compatible versions, for example `MyOtherDep@1.1` and `MyOtherDep@1.2`, can also lead to similar situations.
For example, let’s say `MyPkg` has certain non-functional requirements that require `MyOtherDep@1.2`, like it can be guaranteed that `MyPkg.f()` is allocation-free as long as you load `MyOtherDep@1.2`. In such a case, you don’t want to necessarily restrict the compat in `Project.toml` because users can still use the old version of `MyOtherDep`, it’s just slower. But you do want to test that zero-allocation guarantee in your test suite.
OK, fine, you can just let CI resolve to the latest version of `MyOtherDep`, right? But one day you discover that `MyOtherDep@1.2` has also acquired an extension and hence a compat bound on a different library, `SomeoneElsesIndirectDep`. If you have a _different_ test dependency which also brings in `SomeoneElsesIndirectDep`, then it’s quite possible that this will force your test environment to resolve to `MyOtherDep@1.1`.
If you were diligent enough to include a `test/Project.toml` compat bound on `MyOtherDep`, then you’ll get a nice error saying that the test environment couldn’t be resolved. But if you don’t, then the test will just fail and again you’ll have to figure it out by trawling through the CI logs’ Manifest.
I’ve described concrete cases above, but I think collectively they illustrate the point that it’s good to be explicit and encode semantic information about what versions of deps your tests are _expected_ to pass with. Thus, even if the cases above don’t occur in practice with your package, my opinion is that it’s good practice to add compat bounds anyway for any test dep. Sure, it might become stale - but that’s also true of normal package compat bounds, and it’s certainly no less stale than the complete absence of a bound.
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [July 25, 2026, 6:25pm UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/9 "2026-07-25T18:25:19Z")
Surely, all are valid points. On the other side, packages used in testing fall typically in one of the three categories:
- Packages which also used by the “main” package `MyPkg`
- Test.jl & Co
- Packages which are **not** used directly by `MyPkg`, but still could be used together in a realistic use case.
For the first group, compat limits will be automatically provided by `MyPkg`. For the second one, I’d prefer the test to fail and signal me the need to check. For the last one - even more so: If incompatibilities occure, I’d look for workarounds if possible, or set compat limits (in extras?), or at least document the issue.
---
### Author:  [@penelopeysm](https://discourse.julialang.org/u/penelopeysm)
#### Post date: [July 26, 2026, 7:06am UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/10 "2026-07-26T07:06:25Z")
> [@Eben60](#):
>
> For the first group, compat limits will be automatically provided by `MyPkg`
Yes, that’s true, but the point I was making is they’re not always the same as the test bounds. There are situations where you might not want to restrict the _package’s_ compat bounds, since that has downstream effects on users and their ability to install your package in complex environments. However, you may want to have narrower bounds for testing purposes, since that places no additional burden on your users.
---
### Author:  [@JeffFessler](https://discourse.julialang.org/u/JeffFessler)
#### Post date: [July 30, 2026, 2:47am UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/11 "2026-07-30T02:47:18Z")
i asked the same question here and am awaiting a reply:
> [@PSA: GitHub Dependabot now supports Julia](https://discourse.julialang.org/t/psa-github-dependabot-now-supports-julia/134997/15):
>
> How to configure it if I want dependabot to only manage the root Project.toml and ignore the docs/Project.toml and test/Project.toml? I am getting tons of little PRs for docs/ and test/ and I don’t want to bother with compat for those subdirectories: [https://github.com/JuliaArrays/LazyGrids.jl/pulls](https://github.com/JuliaArrays/LazyGrids.jl/pulls) I asked copilot for help and it strongly suggested using exclude-paths which I tried but gave an dependabot error. And I tried to find documentation on the allowable syntax but all I could find w…
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [July 30, 2026, 10:36am UTC](https://discourse.julialang.org/t/does-it-make-sense-to-define-compat-bounds-in-the-test-project-toml/138466/12 "2026-07-30T10:36:09Z")
See [PSA: GitHub Dependabot now supports Julia - #16 by Eben60](https://discourse.julialang.org/t/psa-github-dependabot-now-supports-julia/134997/16)
All information is provided without warranty.