Re: Unit testing userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joshua Brindle wrote:
> to test is_selinux_enabled() you'd need to mock the fopen() and read()
> functions

You need to realize how much important mocking is. It's not about
mocking the system calls. Instead, it should be used rigorously in all
the tests.

Example: IMO the problem with is_selinux_enabled is that it tries to do
too much in one block of code. To effectively test all the paths through
that function you would get crazy in simulating the right conditions.

Now consider this variant instead:

int is_selinux_enabled(void) {
    if (is_selinux_filesystem_mounted()) {
        return !no_policy_loaded();
    }
    else {
        return 0;
    }
}

int is_selinux_filesystem_mounted() {
    return selinux_mnt || filesystem_detected_the_long_way();
}

int no_policy_loaded() {
    ... the stuff with getcon (notice it is currently duplicated)
}

...

Now each of those isn't too hard to test given you can mock the result
of the individual sub-functions! (And the logical or one liner is so
brutally simple & obvious that it even does not need any testing.)

Given this I would seriously consider a framework that gives this
ability, otherwise you are stuck with doing it manually through
#define's and that would seriously discourage people to unit-test. They
will black-box-test or integration-test instead which will not cover all
the nuances of the function logic and is likely to miss half of the
corner cases, improper assumptions, etc., ie. bugs.

Michal Svoboda

Attachment: pgp5azQ3jmmu9.pgp
Description: PGP signature


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux