On 10/28/2013 02:52 PM, Roberto Polli wrote: > Hi @all, > > Jan 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. > https://pypi.python.org/pypi/fakeldap/0.5.1 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. They will 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. > > Peace, > R. > > -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
