On 10/28/2013 02:52 PM, Roberto Polli wrote:
>>>> as I promised, I am sending you a proof-of-concept code that
>>>> demonstrates, how we can mock DS in unit tests for library function
Ok, that's clear.
>>>> instead of sending command to real DS instance,
>>>> they just store the data in 'dit' dictionary
We could use some monkeypatching lib.
You are correct, we could ! That was
Thierry`s question - we can rewrite
ldapadd,.. methods of DSInstance (monkeypatching), OR define MockDS class with
fake ldapadd,.. and use that one.
>>>> Now I can successfully test that enable_changelog really works,
_really_ is not the right word, right :DDDD
I think it is. The unit test for
enable_changelog really does test the code of
enable_changelog(). It does not test ldapadd, ldapmodify ... methods (that
should be a job for ldapadd`s unit test) and it does not test how real 389 DS
would respond to such request (that is job for 389 DS acceptance, or as you
refer to them, "integration" tests).
It is a unit test.
>>>> this approach would work for 95% of all functions in lib389.
I agree that many functions are just ADD/DELETE, and this will work for that.
Mocking functions involving MOD, default values, simulating errors & co will
be complex though: that's the reason why - even after adding unit tests - I
will leave the integration testings in the same repo.
be part of 389-ds-base repo. If we want to keep them together with
lib389, then lib389 would be merged to 389-ds-base repo. That`s where developers
would like to keep these.
>>>> DSInstance. That is handled by DSModuleProxy. We already went through
>>>> this, but not with Roberto.
Saw the code, it just imports all files in the folder, right? It's a nice
trick, even if it makes the design a bit complex.
Correct ! Takes functions from
modules and makes them "methods" of DSInstance.