Initially, they weren't part of the base package (lib389 was seperate), which is why they are seperate.

Today it would make sense to move them, probably to "dirsrvtest/cli/..." I think. The test/suites are part of integration test, and I think it's important we keep our test name space clean.

The fakeargs exists to try and emulate some behaviours without needing a real cli. I'd love to see what you propse to replace it with, so maybe a longer discussion from you about your ideas? Thanks!

Initially, they weren't part of the base package (lib389 was seperate), which is why they are seperate.
Today it would make sense to move them, probably to "dirsrvtest/cli/..." I think. The test/suites are part of integration test, and I think it's important we keep our test name space clean.

I agree but maybe Viktor will have his own ideas after looking at the existing test suite.
It also involves the creating of topology so it is not just a clean unit test...

The fakeargs exists to try and emulate some behaviours without needing a real cli. I'd love to see what you propse to replace it with, so maybe a longer discussion from you about your ideas? Thanks!

I am okay with it. :) We just need to fix existing issues in the test.
We can either modify the existing tests and add new arguments that are missing (like args.json), either we modify FakeArgs object so it allows set nothing to the optional args.

There is a good reason for it's own seperate topology, and it's to do with forcing the use of the python installer in a certain configuration. I think there are some other reasons too, but I really can't remember them at the moment (I'm sure if I looked at the code, I'd remember)

Fake args is easy to add arguments too though? So maybe I'm not clear on what the limitation is that you have, because you can always just add another "argument".

There is a good reason for it's own seperate topology, and it's to do with forcing the use of the python installer in a certain configuration. I think there are some other reasons too, but I really can't remember them at the moment (I'm sure if I looked at the code, I'd remember)

We should test with Python installer everywhere by now anyway. :)

Fake args is easy to add arguments too though? So maybe I'm not clear on what the limitation is that you have, because you can always just add another "argument".

Yeah, I just listed the issues I found. The fix will be easy for this one.

@spichugi Unless you run --without-perl, I don't know if it does? It depends on some settings in the core of lim389. Perhaps something to review? I certainly know that basic.py fails today if you use --without-perl (I was going to fix it, but I'm sick at the moment :( )

Well, I'm glad it's easy and I look forward to reviewing your work,

Thanks!

I don't know when I'll have the time for this refactoring...
If you'd like to fix it, feel free :)

But maybe Viktor will have some ideas about the tests refactoring and its place in the dirsrvtests.

I'm about to find otu, because I am going to fix some --disable-perl issues tonight/tomorrow, so I'll take alook.

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

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.