[SSSD] [PATCH] Add integration tests

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Mon Apr 20 17:15:17 UTC 2015


On 03/19/2015 07:27 PM, Michal Židek wrote:
> On 03/18/2015 03:48 PM, Nikolai Kondrashov wrote:
>> On 03/18/2015 03:06 AM, Michal Židek wrote:
>
> I see. You mean to test results from getpwall.
> We could do this:
> Create simple asserts like
> assert_get_user_by_uid and
> assert_get_user_by_name
> as described in my previous mail bellow. Than
> create their getpwall ekvivalents like
> assert_getpwall_uid
> assert_getpwall_name
>
> These functions would have the same arguments as
> the simpler asserts (not just one time, but as
> a list).
> In these functions we would first convert the list
> returned by getpwall to a dictionary where the
> uid (name) will be a key and the pwd structure a
> value. Then we would iterate throught the list
> of input values and for each UID (name) we
> would check if the expected value is matching the
> pwd structure (in the same way as the simple
> asserts will do, so the matching part will be
> reusable). The usage would be like this:
>
> uid_expval_list = [(2001, {"name"="user1"}),
>                     (2002, {"name"="user2"})]
>
> assert_getpwall_uid(ldap_conn, uid_expval_list)
>
> Similiar would it be with the assert_getpwall_name.
> Of course we could check for more than just correct
> "name" attribute, but checking just the "name" attribute
> should be possible (we would only test requested
> parts of pwd structure). As you see, we do not
> need to filter any root user if we do it this way
> (yes the root will be there in the returned list
> by getpwall but only names in the uid_expval_list
> will be used).
>
> Anyway, I am OK if the getpwall part is done later
> and for now only the simple asserts are implemented
> and used in the sanity tests.

This looks almost perfectly fine, but it accounts only for checking users that
should be there, yet not for users that *shouldn't* be there. So, I think it
is still better to explicitly remove that one root account and maybe have
variations of assert_getpwall* which check for the absence of extra users.


>>> Also I am not really sure why the src/tests/intg/slapd_setup
>>> and src/tests/intg/slapd_teardown are written in bash.
>>> It would be IMO better to write it all in python. The
>>> few external tools/programs can be called from python and
>>> the rest would be more readable if it was written
>>> in python (like the url_encode function, which to seems
>>> to be somehow cryptic in bash).
>>
>> slapd_setup/teardown are written in Bash for brevity and flexibility.  Bash
>> is designed for easy integration of programs and file I/O. In short, Python
>> needs more syntax and semantic overhead to do these specific things, so
>> growing and experimenting with slapd setup/teardown is going to be easier
>> and faster with Bash, IMO. Although, yeah, some things might be cryptic and
>> once it gets over certain size and complexity it will become less
>> manageable (at that point we certainly should move to Python). It's the
>> usual special- vs general-purpose language trade-off.
>>
>> Still, if for some reason Python is considered more suitable at this point,
>> I can rewrite it, no problem.
>
> I really think that implementing two python functions (slapd_setup /
> slapd_teardown) would be better.

I'm doing a simple Python class hierarchy to accommodate 389-ds support later.
So far the interface is this, basically:

     class DS:
         def setup(self):
         def teardown(self):
         def bind(self):

Nick



More information about the sssd-devel mailing list