On Wed, Apr 03, 2024 at 12:47:15PM +0200, Patrick Steinhardt wrote:
> I very much agree, this thought has crossed my mind multiple times while
> working on the whole reftable saga. Ideally, we would have integration
> tests that write reftables with one of the implementations and then read
> them with the respective other implementation. I wouldn't really know
> where to put those though. CGit is very unlikely to pull in JGit as a
> test dependency. Does JGit have any tests that already use CGit?
We do have some tests that use jgit to check bitmap interoperability.
But obviously they're optional, and I suspect they are not run very
often (I do have jgit in my path these days, so I run them, but I assume
most people don't). It probably wouldn't be too hard to include it in
one of the CI runs, though. You can grep for the JGIT prereq in t/.
We had another test that used jgit to check for some protocol
interoperability. But it was broken with sha256 and nobody noticed. ;)
There I replaced it with a hard-coded input. See 13e67aa39b (v0
protocol: fix sha1/sha256 confusion for capabilities^{}, 2023-04-14) for
some discussion.
I think using actual jgit (versus a hard-coded input) is a good basic
smoke test: it tells us if the two can interoperate generally. But for
testing specific inputs like the case in 13e67aa39b, we are depending on
jgit producing that specific behavior (which in this case, it probably
wasn't any more). And there we are better off just with a manual test
vector.
-Peff
