sure, thank you. I'd look for it.
But, I guess, it is the issue for another single ticket.
Are you agree? Should we create ticket for it?
For now, I'll focus on the repairing current lib389 testing functionality.
On Mon, Oct 19, 2015 at 04:32:48PM +0200, thierry bordaz wrote:
On 10/19/2015 04:18 PM, Mark Reynolds wrote:
>On 10/19/2015 10:02 AM, Simon Pichugin wrote:
>>I am working now on the fixing lib389 broken tests:
>>And it's time for dsadmin_* tests. Can anybody, please, tell me more
>>As I see, Mark and Thierry worked on it, but any other team
>>members are welcomed too. :)
>I think all I did for it was to make it python 3 compliant. I think it
>was a work-in-progress fora future CLI interface. Thierry can probably
>answer this for sure, but it s definitely not being used at the moment.
Hello Simon, Marc,
lib389 comes from https://github.com/richm/dsadmin
After some time dsadmin word was removed from lib389 but you can still find
some reference on it.
The lib389-test have been moved to components tests (replica, backend,
index..) and I think dsadmin is deprecated in those tests.
You may rename some of the dsadmin tests to the component they are testing.
bug_harness.py was used in dsadmin but is no longer used in lib389. If you
can remove the dependency on it (if it exists some) it would be good.
>>I have a few questions:
>>1) What should we do with dsadmin_* tests and its coverage?
>> - for example, we have "TypeError: 'NoneType' object is not
>> - topology.conn.replica.changelog and
>> - topology.conn.backend.add
>> - or "AttributeError: DirSrv has no attribute 'getMTEntry'"
>> - topology.conn.getMTEntry('o=MISSING')
>>And it is only a few revealed after first run.
>>2) Should we rename dsadmin_* tests somehow? (there is no dsadmin
>>3) Do we need bug_harness.py or is it obsolete?
>Again, I think Thierry can answer these questions best.
>>Please, provide me with details.
>>389-devel mailing list
389-devel mailing list