Univention Bugzilla – Bug 35620
[ucs-test] test UCS@school module for creating computer rooms
Last modified: 2016-11-03 17:37:36 CET
Please write an ucs-test script that will test the UCS@school room module that is used to create, modify and delete computerrooms. Please also test if computers may be assigned to/removed from a computerroom.
A new script with the name "25_room_management_module" is created to include: - Testing creating new computer room. - Testing the UMCP get,query commands. - Test editing the exiting room. - Test creating new room with the same name (fails) - Test removing the created room. Tested on single server and multi server environments. This script currently fails because of Bug #35166.
parameter name spelled incorrectly: accept_doublicate_name doublicate → duplicate
(In reply to Florian Best from comment #2) > parameter name spelled incorrectly: > accept_doublicate_name > > doublicate → duplicate Spelling mistake corrected. Class SchoolRoom renamed to be ComputerRoom as suggested.
Ammar, can you please adapt this script to fit the current response. It currently fails because of changes in Bug 35278 because some dict keys (objectType, hosts) were added. You can simply strip them out of the response before the comparison. And maybe: accept_duplicate_name → accept_duplicated_name
(In reply to Florian Best from comment #4) > Ammar, can you please adapt this script to fit the current response. It > currently fails because of changes in Bug 35278 because some dict keys > (objectType, hosts) were added. You can simply strip them out of the > response before the comparison. > > And maybe: accept_duplicate_name → accept_duplicated_name Done.
The test script contains the following lines: # Test creating new room with the same name room2 = ComputerRoom(school, name=room.name, host_members=[computers_dns[1]]) room2.add(accept_duplicated_name=True) → There is no check whether the room really failed to be created (and it currently does not fail, the log does not contain "Cought an expected exception: %s". → Also a check whether the values of room1 are the same as before after the failed command is missing. Logfile: Calling schoolrooms/get for cn=8058-new_name,cn=raeume,cn=groups,ou=8058,dc=mydomain,dc=intranet Adding school room new_name with UMCP:schoolrooms/add param = [{'object': {'school': '8058', 'computers': ['cn=f4dyngbclt,cn=computers,ou=8058,dc=mydomain,dc=intranet'], 'name': 'new_name', 'description': 'ggfa44pgfl'}, 'options': None}] Waiting for replication: OK: replication complete (nid=2297 lid=2297) Done: replication complete.
(In reply to Florian Best from comment #6) > The test script contains the following lines: > > # Test creating new room with the same name > room2 = ComputerRoom(school, name=room.name, > host_members=[computers_dns[1]]) > room2.add(accept_duplicated_name=True) > > → There is no check whether the room really failed to be created (and it > currently does not fail, the log does not contain "Cought an expected > exception: %s". The check is included inside the add function. The module is changed since the time of writing this script, so instead of: 1- return True if addition is successful. 2- throw an exception if add is not successful with a description of the reason. now it returns always an array, where it contains: 1- element true, if add is successful. 2- element false, if add is not successful. Funny enough, the old test script still passes after these changes. I changed the checks to fit the new circumstances. > → Also a check whether the values of room1 are the same as before after the > failed command is missing. I do not see why such a check is needed. It is added though.
Can you adapt check_query() to fit into the same scheme as in the other classes → to accept a list as argument. comment #6 is still valid. You need to do something like: room2.verify_ldap(False) after adding it. It must not exist.
(In reply to Florian Best from comment #8) > Can you adapt check_query() to fit into the same scheme as in the other > classes → to accept a list as argument. > Done. > comment #6 is still valid. > You need to do something like: > room2.verify_ldap(False) > after adding it. It must not exist. This is not possible as long as the DN of an ldap objects is a unique attribute. The script is testing creating a new room with the same name as an existing room, it should fail on the front end, but the ldap object still exists.
(In reply to Ammar Najjar from comment #9) > > comment #6 is still valid. > > You need to do something like: > > room2.verify_ldap(False) > > after adding it. It must not exist. > > This is not possible as long as the DN of an ldap objects is a unique > attribute. The script is testing creating a new room with the same name as > an existing room, it should fail on the front end, but the ldap object still > exists. yes, you are right but the test script now does not fail if the creation of the room would succeed. "should_fail" is only evaluated if "not reqResult[0]".
(In reply to Florian Best from comment #10) > (In reply to Ammar Najjar from comment #9) > > > comment #6 is still valid. > > > You need to do something like: > > > room2.verify_ldap(False) > > > after adding it. It must not exist. > > > > This is not possible as long as the DN of an ldap objects is a unique > > attribute. The script is testing creating a new room with the same name as > > an existing room, it should fail on the front end, but the ldap object still > > exists. > yes, you are right but the test script now does not fail if the creation of > the room would succeed. "should_fail" is only evaluated if "not > reqResult[0]". Right, corrected.
Ok, seems good now.