Unit tests typically run a function or a tevent request without running the full deamon. The unit tests in SSSD are developed using either the check library or the cmocka library. Cmocka should be used for any new unit tests added to SSSD.
The unit tests are fast to execute and in general this is where corner cases are typically easiest to test as you can provide false or unexpected input to the code under test. Unit tests are also often used to test a library’s API.
An important part of many tests using cmocka is wrapping a function provided by an external library using the
--wrap feature. You can learn more about cmocka and this feature in a lwn.net article the cmocka developers contributed. In the SSSD source tree, the unit tests reside under
src/tests/*.c (check-based tests) and
To run the tests, make sure both the cmocka and check libraries are installed on your system. On Fedora/RHEL, the package names are
make check from your build directory will then execute all the unit tests.
Talloc can be a double-edged sword sometimes. On the one hand, talloc greatly simplifies memory management, on the other hand, using talloc creates a risk that a memory related to some operation is allocated using a top-level memory context and outlives the lifetime of the related request. To make sure we catch errors like this, our tests contain several useful functions that record the amount of memory a talloc context takes before an operation begins and compares that amount of memory after the operation finishes. The functions to set up and tear down the memory leak detection are called
leak_check_teardown. Record the amount of memory taken before an operation with
check_leaks_push and then check the amount of memory taken after the operation with
A typical use-case is the sysdb API tests at e.g.
A less typical use-case is testing of the NSS or PAM responders in isolation. The NSS responder test is located at
src/tests/cmocka/test_nss_srv.c. Normally, the NSS responder would require a client such as getent to talk to it through the nss_sss module and would send requests to and receive replies from a back end. In unit tests, the NSS client’s input is simulatd by calling the
sss_cmd_execute directly, but with mocked input (see e.g.
mock_input_user_or_group). The test even fakes communication to the Data Provider by mocking the
sss_dp_get_account_recv request that normally talks to the Data Provider over D-Bus (see e.g. the