Just reading the comments, I agree with the common sentiment that you should have more unit tests than integration tests, but I have come around to the way of thinking that if I only have time to write a few tests then I would rather write E2E tests. This way, at the very least your entire stack is being exercised, and you have a way of ensuring that the happy path is passing consistently, which is the most important flow for an application (even if I'm personally more interested in keeping other flows sane). While I prefer unit tests due to their simplicity, speed and the speed at which they can aid debugging, these days I will only implement them after I have added a few E2E tests.
Rust uses https://github.com/rust-community/bors which maintains a linear queue of PRs which can only land after being rebased onto the commits before the PR and subsequently passing tests.
dlang uses several. One notable one is the "autotester" written by Brad Roberts. It's built to ensure that breaking the D compiler (as tested by the test suite) does not result in commits.
I feel that if you care that much about the internals of the abstraction then you don't necessarily want an abstraction anymore, but rather the concrete thing that is being abstracted over. I think abstraction is an admirable quality that has numerous advantages, but if you need guarantees on the properties of what's under the abstraction then an abstraction is probably not what's needed at that point.
I wrote a bare bones "store-and-fetch" [dotfile tool][1] that's been working well for me, mainly because it's easy to set up on a new device and it delegates a lot of functionality to GitHub. It's more or less equivalent to the "Git repo in home" approach, it just streamlines the `git commit`, `git push`, `git pull` workflow.
Sick of doing manual dotfile synchronisation, and not wanting to have to install yet another tool on every new device, I wrote a bash script that does two simple things: stores the dotfiles you specify in a git repository, and installs dotfiles stored in a specified git repository.
I believe the most innovative part of the tool is its simplicity, in that the dotfiles are stored in a format that still allows them to be easily traversed and edited within the repository, particularly when [using GitHub for storage][1]. In fact, many operations that are expected to be used rarely (compared to storing and fetching), such as deletion, have been delegated to GitHub for simplicity.
Disclaimer: I am [cross-posting][2] `dot` from Reddit in the hopes of gaining more feedback. Please let me know what you think!
