Either it should be transformed to the common case for the admin group (utilizing all attributes in a proper way).
Either it should be removed because creating this kind of account is a special case and I'd rather have it in the test suite code for the better visibility.

Either it should be transformed to the common case for the admin group (utilizing all attributes in a proper way).
Either it should be removed because creating this kind of account is a special case and I'd rather have it in the test suite code for the better visibility. --- removed

These three objectclasses are not related to the pure AdminGroup entry. -- replied

We have AutoMembershipPlugin object for that --- removed and implmented

Please, remove this function and use certain objects for creating proper entries. Like Groups, etc. -- removed and implmented

suff -> suffix (please, try to avoid word shortenning) -- implmented

It is created automatically during backend.create --- removed and implmented

You named it autouserGroups, etc. So why do you create generic OrganizationalUnits instead? --- As we have different backends we need thes generic OUs to create AutoMembershipRegexRules and for other stuff

You create only one user here -- corrected and implmented

We have DSLdapObject.preset() method. It is better and more transparent to use it -- implmented

Only one group is added -- corrected and implmented

I am not sure why you need this but you can use DSLdapObject.ensure_state() here --- implmented ,we need it , please check test_multi_valued_automemberdefaultgroup_with_uniquemember , test_invalid_automembergroupingattr_member etc

What is the second step? I think the function name is misleading -- corrected and renamed

You name it the same everywhere automembers. It is confusing... -- corrected and renamed

Could be done in a for loop with only two arguments -- corrected and implmented

We usually name topology.standalone as instance. So it's a bit confusing -- corrected and implmented

You already has marked it as bz834053. So the name should reflect the issue the test case checks -- corrected and implmented

You reuse Config(instance1) a few times, why not assign it to a variable? -- implmented

It is unclear what you test here... You can add some verb to the name, it'll help probably... --- corrected and implmented

Why not just iterate here? Maybe even through a range() function. --- corrected and implmented

In many test cases, you have only one step but the actual content has 3+ steps. I think the docstring should reflect the main actions at least (no need for overdoing it though) --- Done

Please, go once again through the list of my concerns and check if everything is implemented... Or reply why you haven't implemented it... --- Done

Also, I think the naming is completely misleading:autoMembers - the test suite name already has the word. task and retro_chlog are not the only things there. You test the basic functionality so I think it should be basic or acceptance.

These three objectclasses are not related to the pure AdminGroup entry. -- replied

Then the objectclasses should be created additionally if they are needed for you test case.
In general, AdminGroup doesn't need it.

I am not sure why you need this but you can use DSLdapObject.ensure_state() here --- implmented ,we need it , please check
test_multi_valued_automemberdefaultgroup_with_uniquemember , test_invalid_automembergroupingattr_member etc

Could you please explain the logic why we need to add the object classes exactly at that point and not at the beginning while creating the group?
Probably, I miss something...

Also, I think the naming is completely misleading:
autoMembers - the test suite name already has the word. task and retro_chlog are not the only things there. You test the basic functionality so I think it should be basic or acceptance.

Then the objectclasses should be created additionally if they are needed for you test case.
In general, AdminGroup doesn't need it.

Done

I am not sure why you need this but you can use DSLdapObject.ensure_state() here --- implmented ,we need it , please check
test_multi_valued_automemberdefaultgroup_with_uniquemember , test_invalid_automembergroupingattr_member etc

Could you please explain the logic why we need to add the object classes exactly at that point and not at the beginning while creating the group?
Probably, I miss something...

we have created AutoMembershipDefinition with autoMemberGroupingAttr: groupOfNames (comes from Group type)
now in the test we are changing AutoMembershipDefinition(autoMemberGroupingAttr) with autoMemberGroupingAttr: uniquemember (comes from UniqueGroup type) with existing autoMemberGrouping. newly created user should be added to same host group as uniqueMember and verse versa . Its was just as sigle example.

Still fails here. Have you checked with a clean install from my Vagrantfile?

test_valid_and_invalid_automembergroupingattr fails after 7096094
What test is doing is it changes the objectClass of the group to the incompatible with the members of the group. Previously automember plugin would deny adding a member with the incorrect OC, but since the change above it allows.

Why do you have this line? Even if it's uncommented - it is not assigned anywhere

It was for troubleshooting purpose , now i have removed it .

It is either regression or it is not... It should be clearly defined what it is and it should have an opened tracking issue.

Viktor has already drop a mail to mark regarding this , but till now we did not get any confirmation/reply , so as per his suggestion we have made it xfail , we will create tracking issue after mark's confirmation . till then we have to merge it as xfail as we have to put more test cases on the top of the same module , which are from same TET test script and uses same entries and test functions .