#48303 Fix lib389 broken tests
Closed: wontfix None Opened 8 years ago by spichugi.

lib389 project has broken test suites. They need to be fixed.

Also, some tests use the nose test framework and some don't use any.
It would be nice to port all of them to pytest framework.

Each test suite refactoring should be pushed as a separate patch.


To ​ssh://git.fedorahosted.org/git/389/lib389.git

56e6910..cc215b6 master -> master
commit cc215b6fa7aa5c5bf1c89b29571a408f9631bce4
Author: Simon Pichugin spichugi@redhat.com
Date: Wed Oct 7 14:10:41 2015 +0200

cc215b6..5ce77da master -> master
commit 5ce77daef84088cc731c89d9877adcd04f9d39e3
Author: Simon Pichugin spichugi@redhat.com
Date: Thu Oct 8 15:19:41 2015 +0200

My patch reveal a little issue with imports.
The only way I found to run these tests with 100% PASS is to use imports like this:

{{{
from lib389.init import UnwillingToPerformError
from lib389 import DirSrv, InvalidArgumentError
}}}

So if import, for example, like this:

{{{
from lib389 import DirSrv, InvalidArgumentError, UnwillingToPerformError
}}}

Then in result we have two tests failed, because it can't catch the UnwillingToPerformError exception and goes with this error:

{{{

raise InvalidArgumentError("It already exists backend(s) for %s: %s" % (suffix, ents[0].dn))
E InvalidArgumentError: It already exists backend(s) for o=test_create: cn=test_createdb,cn=ldbm database,cn=plugins,cn=config
}}}

It happens there:
{{{
221 with pytest.raises(UnwillingToPerformError) as excinfo:
222 > topology.standalone.backend.delete(suffix=NEW_SUFFIX_1)
}}}

If anyone has any idea 'why?', please, come with it. For me it looks, like it doesn't recognize the UnwillingToPerformError object properly.

This strange imports also are presented in the '''lib389/backend.py''' library. So may be, Theirry, you know something?

P.S. I tried many other methods of importing these exceptions and it is the only way I found when everything works.

Replying to [comment:4 spichugi]:

My patch reveal a little issue with imports.

Issue was resolved in the ticket:48309.

Pushed to ssh://git.fedorahosted.org/git/389/lib389.git

171cfc8..d945ec2 master -> master
commit d945ec2f4638abe6e1b4287076cc271d86778de7
Author: Simon Pichugin spichugi@redhat.com
Date: Fri Oct 9 18:12:09 2015 +0200

{{{
-#INSTANCE_PREFIX = os.environ.get('PREFIX', None)
-INSTANCE_PREFIX = None
+INSTANCE_PREFIX = '/'
}}}

You can actually just remove all of these because in init.py we have:

{{{
388 args_instance[SER_DEPLOYED_DIR] = os.environ.get('PREFIX', '/')
}}}

So you don't need to set anything for SER_DEPLOYED_DIR

There is also a bit to fix the case where SER_DEPLOYED_DIR gets set to None also to prevent tests breaking, but in this change a few weeks back, I may have had the un-intended consequence of breaking something.

Replying to [comment:9 firstyear]:

You can actually just remove all of these because in init.py we have:

{{{
388 args_instance[SER_DEPLOYED_DIR] = os.environ.get('PREFIX', '/')
}}}

So you don't need to set anything for SER_DEPLOYED_DIR

Ok, thank you. I removed SER_DEPLOYED_DIR from '''allocate(args)''' functions.

But I leave:

{{{
INSTANCE_PREFIX = '/'
}}}

Because I need it for this assertion:

{{{
assert topology.instance.prefix == INSTANCE_PREFIX
}}}

To ssh://git.fedorahosted.org/git/389/lib389.git

d8b89d9..0c24f69 master -> master
commit 0c24f69a917ffd21686e0cabbfa8aa00a01a1ff9
Author: Simon Pichugin spichugi@redhat.com
Date: Fri Oct 23 20:13:28 2015 +0200

Milestone lib389 1.0 deleted

Metadata Update from @spichugi:
- Issue assigned to spichugi

7 years ago

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

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata