attachment
0001-Ticket-48855-Add-basic-pwdPolicy-tests.patch

Minor issue:

_create_user(topology.standalone) should really be checking for exceptions. Any update to the server should be inside a try/except

Thinking about this, I want to leave it.

If _create_user fails, we have bigger problems, and the test probably won't work anyway. If create_user fails, we are just going to fail-out of the test anyway, so I would rather the un-caught exception be passed up (ie ldap.ALREADY_EXISTS or ldap.UNWILLING_TO_PERFORM) rather than masking out the error into a generic exception. We loose data and traceability of a failing test.

A test should really take the mentality of "fail fast". So I think I would like to leave it unchecked in this case.

Is there a specific reason or benefit to checking this do you think?

Replying to [comment:2 firstyear]:

Thinking about this, I want to leave it.

If _create_user fails, we have bigger problems, and the test probably won't work anyway. If create_user fails, we are just going to fail-out of the test anyway, so I would rather the un-caught exception be passed up (ie ldap.ALREADY_EXISTS or ldap.UNWILLING_TO_PERFORM) rather than masking out the error into a generic exception. We loose data and traceability of a failing test.

Well you could still do an assert False, and give a nice error massage as to what went wrong.

A test should really take the mentality of "fail fast". So I think I would like to leave it unchecked in this case.

Is there a specific reason or benefit to checking this do you think?

Just good coding practice - always check for errors. I hear what you saying and I am fine leaving it as is.

Well, I think it's good coding practice for a library (such as lib389). But here I think that doing the assert would mask the underlying causing which we would want to investigate if it did fail?

If your happy, I'm going to push this then,

commit 0058504
Writing objects: 100% (7/7), 2.35 KiB | 0 bytes/s, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
40c2aa6..0058504 master -> master

Correction to original patch.
0001-Ticket-48855-Fix-the-skeleton-password-policy-test.patch

I've applied your patch, but my attempt to run pwdPolicy_test.py still fails like this. Maybe, there's some mismatch in my env? But I cannot find what it is... (Note: my lib389 and 389-ds-base are both up-to-date.) puzzled
{{{
# Say that we accept the cert
# Connect again!

    # Enable the SSL options

  standalone.rsa.create()

ds/dirsrvtests/tests/suites/password/pwdPolicy_test.py:82:

self = <lib389.config.RSA object at 0x7fedbe074f10>, dn = None
properties = {'cn': 'RSA'}

def create(self, dn=None, properties={'cn': 'RSA'}):
    # Is this the best way to for the dn?
    if dn is not None:
        self._log.debug("dn on cn=Rsa create request is not None. This is a mistake.")

  super(RSA, self).create(dn=self._dn, properties=properties)

E TypeError: create() got an unexpected keyword argument 'dn'
}}}

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 issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1915

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.