Tests are missing.

[dbaarda]

There are currently no tests. I should add some.

[dbaarda]

There are starting to be a few tests now that test some of the really simple low level utilities, but nothing yet to test the more complicated functionality. Currently the tests are just using assert() with NDEBUG explicitly undefined. For more advanced testing we may want to use some kind of framework.

Any framework we use should ideally target C, not C++ and be small. It must either be so small we can include it in this repo, or it must have a Debian package in at least the testing repo. Digging around the following meet this criteria;

http://www.jera.com/techinfo/jtns/jtn002.html - a 3 line *.h file, very minimal
https://github.com/bvdberg/ctest - single header file to include, nice color output, simple to use.
https://github.com/Tuplanolla/cheat - one (or 2) headers to include, nice color output, handles crash and timeout.
https://github.com/mity/acutest - yet another single header test framework.
https://nemequ.github.io/munit/#about - 2 files to include in repo, includes cpu usage.
https://cmocka.org/ - libcmocka0.deb, extensive, can work for embedded too, mock support.
http://cunit.sourceforge.net/ - libcunit1.deb, extensive, seems a bit verbose to use.
https://libcheck.github.io/check/ - check.deb. old but still actively maintained.
https://github.com/Snaipe/Criterion - libcriterion.deb, extensive, simple to use, also C++ (implemented in?)

See also;

lcov - Debian package, uses gcov, gives coverage reports.

ctest seems very small and nice. cheat seems a bit more extensive but is maybe less commonly used? cmocka mocks might be really useful and there is an article on using them here https://lwn.net/Articles/558106/. check seems to be an old defacto standard.

This answer talks about including the *.c file to stub out it's dependencies; https://stackoverflow.com/a/1410143/5720535

[dbaarda]

We probably also want some integration tests that run the whole daemon with a faked nss/pam backend and run the ldap CLI tools to query it. For this we probably want some kind of cli or bash test framework. For that we have;

https://github.com/bats-core/bats-core - bats.deb, bash shell testing framework (TAP support).
https://github.com/simonmichael/shelltestrunner - shelltestrunner.deb, cli testing framework.
https://bitheap.org/cram/ - python3-cram, cli testing framework from mercurial.
https://liw.fi/cmdtest/ - cmdtest.dev, cli testing with separate stdout/stderr/retcode files.
https://github.com/mlafeldt/Sharness sharness.deb, git's shell testing framework (TAP support)

shelltestrunner puts cmdline/stdin/stdout/stderr/retcode all in one *.test file and you need to do any setup/teardown in the cmdline bit. cmdtest has separate files for each of them, and has good setup/teardown support in separate files. cmdtest also includes another "yarn" scenario testing framework that looks interesting.

sharness looks pretty simple to use and is used by git, with TAP support.

[dbaarda]

After looking at ways to fake/stub NSS and PAM, I quickly realized that being able to do this might actually be a useful feature in the program itself, not just for testing.

So I added -R chroot support to be able to run it in a chroot with a different NSS/PAM setup. Getting this to work showed just how complicated PAM is, as the chroot needed large numbers of pam modules and supporting libraries to work. This prompted me to add -N support to use NSS and crypt for auth instead of PAM, and now a chroot only needs passwd/group/etc files and nsswitch.conf to work.

Finally so that tests can be run without requiring root access, we can use fakechroot. I'm not sure if we also need fakeroot, but it all seems to be getting close to workable.

I'm also considering adding a cmdline that directly reads passwd/shadow/etc files instead of using NSS, but TBH with chroot support I'm not sure it's needed.

[dbaarda]

One thing about chroot and setuid; you need to start running as root for them to work. This is a PITA for running tests, since no-one wants tests running as root.

Fortunately there exists fakechroot and fakeroot! In particular fakechroot means we can run tests in a chroot without needing to run them as root.