[andrewfong]

Similar concern here about the lack of snapshot files. Can "locally stored" captured data points be version controlled, even if it's some special Touca binary that makes no sense in GitHub?

I'm coming at this from a "how would I integrate this into my existing corporate setup" perspective. I'm concerned less about UX and more just how it works.

If I interact with Touca via a local client that doesn't to the Internet, and the actual data points are exchanged entirely via Git, that's a much easier sell than another server that I have to ask SREs to maintain. And being able to say "it's just Git + a local client" makes it easier to reason about concerns like "what if we switch to GitLab" or "how would this integrate into our own bespoke CI/deploy pipeline".

[pejman_gh]

Hi Andrew, to clarify, we do support generating local snapshot files in either JSON or Binary with FlatBuffers format (see https://touca.io/docs/sdk/capturing/#locally-storing-test-re...). We also provide `touca results` which helps with managing binary result files (see https://touca.io/docs/cli/results/). So it is possible to forgo the Touca server and just use the SDKs to capture values of interesting variables or runtime of important functions.

Storing test results in Git and comparing them via external tools may make it easier for teams to get started with Touca. But we care a lot about the developer experience and think that having a remote server take care of storage, comparison, visualization, and reporting could make a lot of sense for teams building serious software.

Touca has several components that work great together but you can certainly pick and choose and don't have to use all of them. We like Touca to do as much work as possible including integration with CI so that tests run continuously. But that integration is also optional. If teams have a different CI than GitHub Actions, they could call `touca test` as a CI step instead of using our plugins.

Does my explanation address your concern?