Please, avoid a redundancy.
You have 4 nearly similar 'create' functions. You can unite them into one.

I don't see how ['Accounting', 'People'], ['Product Development', 'People'] and ['Human Resources', 'People'] are related to the test case. It looks redundant to me

Can you iterate here? Like you can have 'user1', 'user2', etc. And you can have 0001, 0002, etc.
No need for the long hardcoded list

I see no reason for encapsulation here. It is used only once. Also, we have create_test_user function which creates a simple test user.

Typo

Does it really return 0?

You named it final.
What is the meaning behind that in regards to the whole filter test suite layout?

You named it final.
What is the meaning behind that in regards to the whole filter test suite layout?

I have named it final as its the final script which uses filters directly to the script like FILTER_MWARD = "(uid=mward)"

Does it really return 0?

Yes , have tested with both :
assert not Accounts(conn, DEFAULT_SUFFIX).filter(real_value)
and
assert len(Accounts(conn, DEFAULT_SUFFIX).filter(real_value)) == 0

both works fine

Can you iterate here? Like you can have 'user1', 'user2', etc. And you can have 0001, 0002, etc.
No need for the long hardcoded list

can you please elaborate m i am confused here

@spichugi all other changes are done as per your suggestion

Can you iterate here? Like you can have 'user1', 'user2', etc. And you can have 0001, 0002, etc.
No need for the long hardcoded list

Now i got it , some filters needed the room number, now i have changed the filter accordingly .

@spichugi all changes are done as per your suggestion

I have named it final as its the final script which uses filters directly to the script like FILTER_MWARD = "(uid=mward)"

It doesn't make sense when you just see the list of test suites in the directory.
Test suites should be named after its functionality. Also, it should be unique across the list (so there should be no match_test_1.py, match_test_2.py, etc.)

Does it really return 0?

Yes , have tested with both :
assert not Accounts(conn, DEFAULT_SUFFIX).filter(real_value)
and
assert len(Accounts(conn, DEFAULT_SUFFIX).filter(real_value)) == 0
both works fine

Accounts(conn, DEFAULT_SUFFIX).filter(real_value) does not return 0.
len() returns 0.
Please, fix the docstring according to filter function expected functionality.

Please, develop the solution that calls create method only once here.

The goal is to get rid of redundancy, you haven't done it by developing the current solution. In fact, this solution looks even more confusing because of the line of ifs and args manipulations. Please, avoid it.

@spichugi all changes are done as per your suggestion

Why do you use kwargs in stead of simple arguments here?

If you want to log, use log methods

@spichugi all changes are done as per your suggestion

As I wrote in a comment:
https://pagure.io/389-ds-base/pull-request/50468#comment-92292
Please, don't name test suites like match_test_1.py, match_test_2.py, etc. (you named it basic_test_1.py)

If you think it belongs to basic test suite, put the code to basic_test.py

One more

@spichugi all changes are done as per your suggestion

It should end with test.py. It is done for discoverability.

Also, you can give filter_apply_and_verify.py name to basic_filter_test.py and vfilter_simple_test.py and it will still be true. So your name is not unique.

It should end with test.py. It is done for discoverability.
Also, you can give filter_apply_and_verify.py name to basic_filter_test.py and vfilter_simple_test.py and it will still be true. So your name is not unique.

Please suggest me name , i will apply to it . Or should i put the code to basic_test.py

It is part of the job - name functions, test suites, etc. so they are discoverable, unique and easy to support. We spent brain energy in the beginning so in the future it is easier for other people to maintain it.

You are here for some time already, you upload a lot of code and it is good and we really appreciate it. And the thing that you can improve is to learn the skill of putting together better maintainable code by yourself (we still spend 20+ comments where we rewrite big chunks of the test suite - it eats a lot of time and energy of the reviewer - which is effectively the money of the company).
But I am really up to spending a lot and a lot of my time so you can learn to do things by yourself at a very good quality level. So you can learn different mind tricks of getting better at our job.

Also, as a very important step that I think you are capable of doing - is to make the small decisions regarding your code. :) Like this one. It is the thing when you can distinguish between logical decision and opinionate decision, - slowly, raising your confidence.
This decision is like that. You can either name it in some unique logical way or you can move it to basic_test.py.
All of this is a brainwork that we are paid for.
Hope it helps :)

@spichugi renamed the script name to : filter_with_non_root_user_test.py

LGTM

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3525

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.