On 10/07/2015 04:13 PM, Jakub Hrozek wrote:
On Wed, Oct 07, 2015 at 04:02:32PM +0300, Nikolai Kondrashov wrote:
> On 10/06/2015 12:27 PM, Jakub Hrozek wrote:
>> On Wed, Sep 30, 2015 at 06:15:52PM +0300, Nikolai Kondrashov wrote:
>>> Hi everyone,
>>>
>>> Here is a patch set fixing some things in integration tests and adding more
>>> LDAP tests:
>>
>> (Not a full review, just adding my ideas and impressions)
>>
>> I read these patches when I tried to add tests for the failing POSIX
>> check. That didn't work out, but at least I have a better idea about the
>> integration tests now :-)
>
> Was the problem with the integration test framework or with something else?
> If it's the former, can I offer my help?
No, it was that while the code that triggered the error was in the
generic LDAP provider, the bug itself manifested only in AD provider..so
we'd need to wrap Samba to really test the bug.
Well, I can help with *that* :)
>> Most importantly, the current tests are largely using
enumeration. That
>> not wrong and we want this codepath to be tested, but it's not the
>> default of SSSD, so we want the non-enumeration also.
>
> Alright, I'll try to use the py.test fixture parameters for this. It's a
> cumbersome facility, but perhaps we can use it. If that fails, I'll try
> something else.
>
> I worry a bit about the doubled test runtime, though. Can we have some tests
> running only with either disabled or enabled enumeration?
Maybe..in general I think non-enumeration are more important so if the
rigorous/essential parameters also apply to which integration tests we
run, then I would prefer non-enumeration tests.
Alright. I think we can arrange limiting the number of tests for the essential
run, somehow, if need be.
> Riiight, I completely forgot about the other schemas. Sure,
we'll need
> something more than a boolean. However, how about we define a couple constant
> string variables and supply them instead of literal strings to reduce the
> likelihood of typos?
Yes, that's even better. Would you prefer if I sent such patch (atop
your patches) ?
Err, no, I think I'd better do it myself, thank you :) I'll be changing these
parts anyway.
Nick