[SSSD] More upstream CI tests

Lukas Slebodnik lslebodn at redhat.com
Fri Aug 28 13:16:57 UTC 2015


On (19/08/15 23:38), Jakub Hrozek wrote:
>Hi,
>
>as we're stabilizing the 1.13 branch and before we plan what we want to
>work on during the 1.14 development, we should use that time to write
>some more tests!
>
>Here are some areas where we could add tests. Please discuss or add your
>ideas, I would like to turn this list into tickets we can start
>implementing:
>
>* Extend the LDAP provider tests with more dynamic test cases.
>    - add a user to a group, run sss_cache, assert id user displays the
>      new group and getent group displays the new member
>    - conversely with removing users from groups
>* Background refresh
>    - could be built atop the LDAP NSS tests as well. I think we have
>      all the infrastructure in place.
>* Local overrides integration test:
>    - this could be relatively easy, just call the overrides tool and
>      request the entry. Could be built atop the existing LDAP tests
>      or even use the local provider.
Firstly, we need to prepare test cases for this feature.
We can inspire in downstream ipa-views test case.
After review of test cases we can split it to several tickets.

>* Add a KDC
>    - until we have a pam_wrapper, this would only be useful to test
>      ldap_child, but adding the KDC instantiation might be worth it
>      nonetheless
>    - there is a protorype of KDC instantiation on the list for some
>      time now, since we enabled rootless SSSD
>* IFP - could we reuse the existing sbus tests to spawn a custom bus?
Someone need to look into running dbus-daemon in cwrap env.

Then we need prepare test cases ...

>* SUDO - can we trick sudo into connecting to our test sssd instance?
>

>I think the order of priority is roughly as above. I think the LDAP
>provider is critical enough to be well tested. The refresh and local
>override tests might be nice to have because we would be refactoring the
>NSS responder in 1.14, so we should have it tested.
>
>I'll be happy to hear other opionions, though!
We can try to prepare fake AD in openldap (if possible)
and test basic functionality with ldap provider.

But we need to file tickets for each idea.
(+ maybe assign someone)

LS


More information about the sssd-devel mailing list