All of this boiler plate is not needed, it's part of topologies now.

If the point is to test an offline import with a non-accessible ldif, whdy do you need to generate an ldif at all in _test_setup?

It may be better to choose a more "guaranteed" to not exist name, because this seems like a common pattern to put an export.ldif in /root. Perhaps something like /tmp//export.ldif?

Hope that helps, I think you can actually shrink and minimise this test case while retaining the goals behind it.

The newline after """ usually introduced trouble for betelgeuse to correctly generate xml for importing tests to Polarion.

Please modify the docstring to this format:
"""Export with db2ldif ...

:id: ca91eda7-27b1-4750-a013-531a63d3f5b0

(there is no space between """ and Export just for clarification)

Thanks!

All of this boiler plate is not needed, it's part of topologies now.
Yes, right, removed.

If the point is to test an offline import with a non-accessible ldif, whdy do you need to generate an ldif at all in _test_setup?
The point is to test an offline export, my mistake the log.info comment was wrong. So the ldif generation and loading at _test_setup is to have fresh entries to be exported.

It may be better to choose a more "guaranteed" to not exist name, because this seems like a common pattern to put an export.ldif in /root. Perhaps something like /tmp//export.ldif?
I chose /root initially because it is not accessible by dirsrv, owner of the export task by default. But you're right, a more doubtless non existent path is better. I changed this.

I also removed the newline after """.

Could you please review, thanks !

Thanks for applying the feedback @sgouvern I'll be reviewing this again today :)

If the point is to test an offline import with a non-accessible ldif, whdy do you need to generate an ldif at all in _test_setup?
The point is to test an offline export, my mistake the log.info comment was wrong. So the ldif generation and loading at _test_setup is to have fresh entries to be exported.

In topologies there is already a backend (userRoot) that is populated with sample entries, so the number of entries won't affect the test of the export function - so I think you don't need the ldif generation at all, you can just immediately attempt the export to the non-existant location, which should reproduce the issue too shouldn't it?

Thanks again! I think after that comment I'm happy to accept this :)

@sgouvern
This is better, but please add the newline before id.
Like here:
https://pagure.io/389-ds-base/blob/master/f/dirsrvtests/tests/suites/clu/repl_monitor_test.py

Sorry about the confusion :)

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/4278

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.