All of the above said, I would really prefer to see this test split into a few
smaller ones, each invoking a (possibly shared) py.test fixture separately.
Since py.test doesn't really support nested tests (argh!), we'll need to have
them flat.
E.g.:
* simple override (both with and without FQNs)
add entries
assert entries are not overriden
add override
test entries are overriden
* root override
add entries
assert entries are not overriden
add override to root
test entries are not overriden
* override of override
add entries
assert entries are not overriden
add override
assert entries are overriden
add override of override
test overrides are overriden
* override removal
add entries
assert entries are not overriden
add overrides
assert entries are overriden
remove overrides
test entries are not overriden
* override export/import
add entries
assert entries are not overriden
add overrides
assert entries are overriden
export overrides
remove overrides
assert entries are not overriden
import overrides
test entries are overriden
Making a single test out of all these is tempting, but they are testing
different assertions and shouldn't depend on each other. Otherwise reading
such a merged test and debugging a failure will be difficult.
By "assert" above I mean verifying the setup of the test, and by
"test" I mean
doing the actual test's check. In theory, everything before "test" should
be a
part of the test's fixture and what starts with "test" should be the
actual
test. However, it might not be so easy to do with py.test. Unfortunately,
py.test doesn't distinguish coding assertions from test assertions, hijacks
the stock "assert" statement, and I expect will get confused if you use them
in fixtures, but I haven't tried the latter.
We can probably build fixtures for these tests by calling some of the higher
ones from the lower ones.
The above also applies to the group override tests and tests in general, but
I'll not be repeating myself.
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel Nick I went ahead and
started to reworking the patch in the direction you proposed. Could you check that this
wip patch is what you had in mind? Thanks!