On Thu, Oct 08, 2015 at 08:02:45AM +0200, Lukas Slebodnik wrote:
On (07/10/15 17:42), Pavel Reichl wrote:
>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
>>>>>work on during the 1.14 development, we should use that time to
>>>>>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
>>>>>* Extend the LDAP provider tests with more dynamic test cases.
>>>>> - add a user to a group, run sss_cache, assert id user displays
>>>>> 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
>>>>> all the infrastructure in place.
>>>>>* Local overrides integration test:
>>>>> - this could be relatively easy, just call the overrides tool
>>>>> 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 not customer.
>>which cannot be easily tested (whithout greping log files or touching/checking
>> 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
duplicate effor means when two persons do the same.
Could you explain how is this related to the fact that tests were not prepared
1) I actually think tests not prepared by author are better, author
might be coding in a 'tunnel vision' way, only touching the comfortable
2) There was no time at the time we were writing the local overrides
feature. Yes, it's bad that we completely underestimated the local
overrides effort, but it happened and now we need to deal with it.
And writing tests is a good way of dealing with no tests :-)
(I kinda agree about the ticket priority part, but I'm also happy we
have more tests...the PAM responder tests will come next, I'm sure)