On Feb 26, 2014 5:16 AM, "Colin Walters" <walt...@verbum.org> wrote: > > On Wed, Feb 26, 2014 at 8:09 AM, Stanislav Ochotnicky < sochotni...@redhat.com> wrote: >> >> "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". > Integration tests and unittests really have different purposes. Integration tests test that things that you want to do aren't broken by a change. Unittests test that individual functional units aren't broken by a change.
For a developer who can run their tests right after each commit there's likely not a lot of difference. For someone who's getting a code drop with hundreds of commits in it, however, it's often easier to debug what's causing a failing unittest than what's causing a failing integration test. The reason is that ideally unittests isolate a small piece of code for testing. when it fails, the Unittest itself provides the clues to the person debugging as to where the failure lies. -Toshio
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
