"I" didn't name them. I used standard names for different testing levels as defined by software engineering bodies. Quoting from SWEBOK:
Yes, I think they're wrong. Well, "suboptimal" is a better word.
During making glib changes you should run glib unit tests to have some basic level of assurance you didn't introduce regressions or unwanted changes.
The *very first* test I run is "does the OS still boot"? That's called "smoketest" for me, and it only takes a few minutes.
Yes, after every change, even just an updated translation, I boot the OS, run through systemd, gdm, gnome-shelll, and everything and ensure it still logs in.
This is *before* I run the GTK+ tests or the glib tests or any other test. Why? Because if that fails, there's *no point* to running the other tests. The system is broken. The originating change is investigated and is up for reverting. Whether or not the GKeyFile test pass or not is irrelevant.
(Also, there is the fact that InstalledTests are guaranteed to be run in a logged in desktop, not a mock chroot, so the above needs to work anyways)
It's great that your change helped with discovering issues but perhaps your original testsuite was mixing different levels of testing in the same code. Unit tests are supposed to be quick, dirty solutions using mock objects and other "hacks" to allow of testing with small granularity.
Ah, but if one makes "integration tests" very fast and easy to run as I have, then there's less need for "quick and dirty".
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
