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