2014-02-26 14:11 GMT+01:00 Colin Walters <walters@verbum.org>:

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.

That seems to be optimizing for bugs that break the boot, when bugs that occur in less-frequently used parts of the system are far more common; a lot of software is not used, or not critical, in the boot path.

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.

That would make sense if running the whole battery of tests after every commit were both free and very fast. What I see around me, however, is that there is never quite as much hardware as everyone would want to use, and full test runs of the system take days. So, testing after every commit is impractical, and when one starts with "the system fails to boot", backtracking down to the offending commit in the whole system is rather a lot of work.

Starting with the small-scale unit tests is a more efficient use of resources: the tests are smaller and run faster, so it is actually practical to run them after every commit (or at the very least before any git push or other release of the component visible to other people).

Mirek