Yes and yes. openSUSE's automated testing builds each package not just in a chroot but a new barebones VM, to ensure that depdndency definitions are complete. I've seen Fedora devs remark about how they don't have that kind of budget to throw as, e.g., COPR builds, the implication being that they have to put more engineering into their testing infrastructure. (Sorry, it was years ago and I don't have the energy or time to source it.)
Those VMs are accompanied with screen scrapers that perform OCR in order to automatically test the pre-boot environment, before a display server comes up.
It is possible that other distros are catching up here (I know nixos-tests can include virtualized, multi-machine, networked integration tests, for some packages, for instance). But this testing infrastructure for openSUSE is quite mature. See, e.g., this presentation from nearly a decade ago: https://www.youtube.com/watch?v=2K6ZmvIOtPw
As for Debian, the greater centralization of openSUSE's package sources is perhaps worth emphasizing as a major difference here. For openSUSE, package sources are all checked into special VCS system that is part of the Open Build Service (which is capable of tracking and building external packages, including packages from other distros as well). With Debian, package sources are uploaded as binary artifacts by maintainers who can all have their own standards for style/conventions, testing, and other policies. It's not as easy to get a. God's-eye-view of Debian. This blog post provides some general insight into quirks of Debian's non-standardized processes, perhaps a few years out of date now (I don't know), but I hope it makes clear how it might be plausible for a smaller distro to have more mature centralized, automated testing: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
> Debian generally seems to prefer decentralized approaches over centralized ones. For example, individual packages are maintained in separate repositories (as opposed to in one repository), each repository can use any SCM (git and svn are common ones) or no SCM at all, and each repository can be hosted on a different site. Of course, what you do in such a repository also varies subtly from team to team, and even within teams.
> [...]
> When you want to make a package available in Debian, you upload GPG-signed files via anonymous FTP. There are several batch jobs (the queue daemon, unchecked, dinstall, possibly others) which run on fixed schedules (e.g. dinstall runs at 01:52 UTC, 07:52 UTC, 13:52 UTC and 19:52 UTC).
> Depending on timing, I estimated that you might wait for over 7 hours (!!) before your package is actually installable.
Debian is an amazing project and it's no happenstance that it has served as the base for many successful distros as well as thrived in its own right for many years. But there's some social and technical cruft there that leaves room for some competition, isn't there?
(It looks like nowadays Debian has actually adopted SUSE's openQA as part of its automated testing stack: https://openqa.debian.net/)
I have a fuzzier picture of how OBS/openQA compares to Red Hat and Fedora's package building and testing tools! You've reminded me that I'd like to learn more about that. But do dig into OBS to get a sense of how SUSE is built. It may even be useful to you: their build cluster offers lots of free compute and it'll let you build and host repos for free— even of other distros like Debian and Red Hat.
None of the tooling questions are the real stuff, though— the real stuff is the predictability and freshness of openSUSE Tumbleweed, which users of other rolling release distros tend to speak favorably about once they've tried it.
Elements of that famous 'balance' are quantifiablw. Check out how openSUSE ranks on overall package freshness: https://repology.org/repositories/statistics/pnewest
Tumbleweed is substantially more up-to-date than Fedora Rawhide, but is also markedly more stable and more committed to stability— the expectation is generally that Tumbleweed should be highly usable by and reliable for non-experts, but the expectation for Rawhide is that it exists primarily for Fedora developers and any breakage is on you.
I'd be happy to compare zypper (and dnf) to apt and all (I admit I've not used Void Linux). I've gotta go for now!