On (07/10/15 10:23), Jakub Hrozek wrote:
On Wed, Oct 07, 2015 at 08:58:32AM +0200, 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:
> >> >Hi,
> >> >
> >> >as we're stabilizing the 1.13 branch and before we plan what we want
> >> >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
> >> >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
> 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:
> > https://fedorahosted.org/sssd/ticket/2732
> >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
> which cannot be easily tested (whithout greping log files or touching/checking
> internals in sysdb)
Yes, if Pavel didn't start on #2732 yet, then we can move it down, I
agree PAM responder tests have bigger priority (also in Trac:
major > minor), but..
Both of these ticket are in state new.
> BTW if the tests were ready together with feature it would be something
> different. It would not be a duplicated effort.
> If we really want to duplicate effort then it would be better to see/review
> a test plan for local views.
..it's not completely useless though, we will refactor sssd_nss in 1.14,
so we should have tests for views as well.
But it would be also tested by downstream so we could use their tests.
> Transforming to pytest should be a trivial task.
> Should I file a ticket?
I'm not sure I understand? From the start I thought localviews tests
would be in pytest, running tools and then getent..
I was writing about test plan for local views. It should be prepared/reviewed
in advance. So should I file a ticket for preparing test plan?
or do we want use test plan from downstream.
> >> >* 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 ...
> >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
> by downstream.
I think we should focus not only on what is untested, but what is untested
and will be changed in the next release. Currently we have too much untested
code :-) I know we will change the NSS responder and the LDAP provider so
we need tests for those (we already have some for NSS).
We do not have a lot of time for this. So we should not waste it.
There is possibility to use downstream tests. So why should we duplicate
effort. IFP is not tested at all. The tests for IFP could be used as an
example/howto for other projects which would like to use IFP.
So if we will change IFP in 1.14, then yes, otherwise I would prefer
add more LDAP tests and Samba first..
If we have a time then we can implement additional tests for LDAP or Samba.
We it's very likely it will take a long time to setup more samba-dc in cwrap.
So +1 for sample test for samba, but not for full tests. But it would be better
to focus on part which are not tested at all or for preparing sample test
for each use case (setup samba4-dc, setup dbus-daemon, sample test for pam ...)
If sample tests are ready then additional test can be written as part of
> 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
> >> >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?
I'm going to write tests for pam_sss.so as part of working on
pam_wrapper, feel free to file a ticket and assign to me..
It's better if you
assign yourself :-)