DRSUAPI interface - test case scenarious

Kamen Mazdrashki kamen.mazdrashki at postpath.com
Mon Aug 31 09:29:42 MDT 2009


I've started with refactoring currently implemented test for DRSUAPI - 
you know, it is always easier to step on someone's work claiming it is 
not perfect, rather than creating something on your own ;).

Current work in progress is published on:

Also, I am attaching to this e-mail commits to propagate torture_context 
in Crack Names tests - the problem with current implementation is that 
it is failing and the error message is something like "test failed: 
unknown failure" - after some digging I found out it is the 
'test_DsCrackNamesMatrix()' that fails because of it does not handle 
After test refactoring, test fail pretty clean and one can quickly find 
the exact spot of failure.

After this I am heading toward GetNCChanges() call - I hope to make some 
progress quickly.

On 8/25/2009 1:22 PM, Stefan (metze) Metzmacher wrote:
>> TC1: Test case for DsGetNCChanges() (IDL_DRSGetNCChanges) method:
>> 1. Call drsuapi_DsGetNCChanges() to get highest USN
>> 2. Add attribute, object, whatever
>> 3. Call drsuapi_DsGetNCChanges() - check replica contains added objects in step 2
> We should be careful with other changes also being replicated, maybe
> other local application on the dc have done some changes at the same
> time. But we should also try to detect that an origin update triggers
> changes on more than one object, e.g. the rid counter... we should also
> verify this things.

We can bypass this by implementing fuzzy validation of data replicated - 
i.e. if I create a new user and receive back at list this new user 
record, then everything is fine.
I can't quite get why we should detect if our updated of AD data 
triggers other changes? I am too green in replication and AD world 
indeed but in my mind, replication interface is a separate entity - rid 
counter update on the other hand is AD specific behavior?

> You could also have a test that verifies the order the objects and
> linked attributes are returned. E.g. verify all attributes with DN
> syntax and all drsuapi_DsReplicaObjectIdentifier structues that the
> guids are already known by when we receive them.
> Then you can also check for differences depending on the
> drsuapi_DsReplicaNeighbourFlags flags. I assume
> differences, but maybe others too.

I am still 'decoding' this paragraph :).
As I said earlier - I am still very 'green' in replication - guess I 
need a little bit more reading/debugging to quite get it.

> We also need to tests for the DsAddEntry() call, which is used
> by a dc promotion.

A little help with DsAddEntry() call will be appreciated - as far as I 
understood, replication graph should be build before performing 
scheduled or on-demand replication. I.e. I need to add my machine in the 
graph using DsAddEntry() call - is that correct?

Many thanks for your support,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
18 Macedonia Blvd. Sofia 1606

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-tort-Implement-setup-and-teardown-for-DRSUAPI-t.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090831/4f26b030/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-tort-Helper-function-to-get-DC-info-for-testing.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090831/4f26b030/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0003-tort-DsCrackNames-propagate-torture-context-to-al.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090831/4f26b030/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0004-tort-RPC-CRACKNAMES-test-case-refactored.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090831/4f26b030/attachment-0003.ksh>

More information about the samba-technical mailing list