On 10/07/2015 08:58 AM, Lukas Slebodnik wrote:
On (31/08/15 12:31), Jakub Hrozek wrote:
> On Fri, Aug 28, 2015 at 03:16:57PM +0200, Lukas Slebodnik wrote:
>> On (19/08/15 23:38), Jakub Hrozek wrote:
>>> 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
>>> * 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
There are some tests on list, but still it wuld be good to se a test plan.
>>> * 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.
> We already do:
> It 'just' needs an assignee..
IMHo this should be a very low priority ticket. It's already tested by
downstream and they will have automated tests. We should focus to other parts
Well our integration tests already found at least one real nasty bug in sss_override so I
suppose that it's only good that the priority was higher and bug was found by us and
which cannot be easily tested (whithout greping log files or
internals in sysdb)
BTW if the tests were ready together with feature it would be something
different. It would not be a duplicated effort.
I'm not sure what you mean by
duplicate effort but if you are referring to the fact that intg. tests were not prepared
by the author of the feature then I have to disagree. I have found 2 documentation issues
which would hardly by found by the author
as he already know how the feature works. I believe that documentation issues are high
priority as one of our major goals is to make SSSD more user friendly.
If we really want to duplicate effort then it would be better to see/review
a test plan for local views. Transforming to pytest should be a trivial task.
Should I file a ticket?
>>> * 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
>>> - 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 ...
> Well, the first testcase could be to run introspection -- that would
> validate the bus is accessible.
> It could be the first ticket, if you agree, I can file a ticket and
> assign it?
cwrap test for IFP should have the highest priority because it's not tested
The first two tickets can be done in parallel.
>>> * SUDO - can we trick sudo into connecting to our test sssd instance?
I thought it could be tested using pam_wrapper
I filed a generat ticket for authentication + authorisation
It can be split into testing pam provider and sudo provider.
>>> 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.
> I would like to talk to Andreas next week and ask about Samba. I hope
> this would be much easier and more robust.
Just for the record, here is a link to samba4-dc tracking ticket.
But I think we will need to test with SSL or TLS, so here is another ticket
Did I miss something?
sssd-devel mailing list