Hi @all,
Jan wrote:
I am in fact
creating MockDS class with custom ldapadd,
actually I agree with Jan about how the
mocking process works:
1- reuse/create an ldap mocking class;
2- rewire existing tests on the mock;
Hence, a unit test.
Ok, I agree to add unit-testing. Just I
don't want to move integration tests
(the one against a real instance) in another repo.
I'd leave the integration tests there so that whenever somebody clones he can
test if the lib works for his installation.
It will *not* verify the correctness of ldapadd method of real
DSInstance
class (that is the job of ldapadd`s unit test
About testing ldapadd & co, we
should consider that - as of now - lib389 wraps
some python-ldap methods with *args, **kwds.
We should even be more consistent in parameter names between wrapping and
wrapped method .
Peace,
R.
On Tuesday 29 October 2013 14:18:59 Jan Rusnacko wrote:
Hello Thierry,
I am not rewriting ldapadd,... methods of "real" DS class, I am in fact
creating MockDS class with custom ldapadd,... methods, _just_ like you
suggest :)
Furthermore, you can view it as a subclass of "real_ds" - even though it is
not a proper Python subclass, it inherits all functions from repl module
just like "real_ds" would (again through ModuleProxy mechanism). So,
methods that are defined in repl are the same for "real_ds" class and for
MockDS class, but ldap.. methods are different. So, basically exactly what
you suggest :)
Code of the whole class along with all methods is in file
tests/test_dsmodules/conftest.py line 7.
Thank you,
Jan
On 10/28/2013 12:02 PM, thierry bordaz wrote:
> Hi Jan,
>
> That is very impressive POC, far above my skill in python. Thanks for
> sharing this.
> I have a novice question.
> This implementation overwrites the basic ldapadd,ldapsearch...
> function of
> the "real" DS.
> An other approach is to write a 'mock_ds' class being a subclass of
> 'real_ds' and to overwrite the ldapadd,ldapsearch in mock_ds class (to
> store data into a dict). What would be the advantages of your
> approach ?>
> best regards
> thierry
>
> On 10/25/2013 09:36 PM, Jan Rusnacko wrote:
>> Hello Roberto and Thierry,
>>
>> 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 (see
>> attachment). You can run tests just by executing py.test in tests
>> directory.
>>
>> Only 3 files are of interest here:
>>
>> lib389/dsmodules/repl.py - this is a Python module with functions - they
>> expect DS instance as the first argument. Since they are functions, not
>> methods, I can just mock DS and pass that fake one as the first argument
>> to them in unit tests.
>>
>> tests/test_dsmodules/conftest.py - this file contains definition of mock
>> DS
>> class along with py.test fixture, that returns it.
>>
>> tests/test_dsmodules/test_repl.py - this contains unit tests for
>> functions from repl.py.
>>
>> What I do is quite simple - I override ldapadd, ldapdelete .. methods of
>> mock DS class, so that instead of sending command to real DS instance,
>> they just store the data in 'dit' dictionary (which represents content
>> stored in DS). This way, I can check that when I call e.g. function
>> enable_changelog(..), in the end DS will have correct changelog entry.
>>
>> To put it very bluntly - enable_changelog(..) function just adds correct
>> changelog entry to whatever is passed to it as the first argument. In
>> unit
>> tests, it is mock DS, otherwise it would be real DS class that sends real
>> ldap commands to real DS instance behind.
>>
>> Now I can successfully test that enable_changelog really works, without
>> going into trouble defining DSInstance or ldap calls at all. Also, I
>> believe this approach would work for 95% of all functions in lib389.
>> Another benefit is that unit tests are much faster, than on real DS
>> instance.
>>
>> Sidenote: even though everything is defined in separate namespace of
>> 'repl'
>> module as function, in runtime they can be used as normal methods of
>> class
>> DSInstance. That is handled by DSModuleProxy. We already went through
>> this, but not with Roberto.
>>
>> Hopefully, now with some code in our hands, we will be able to understand
>> each other on this 'mocking' issue and come to conclusions more
quickly.
>>
>> Let me know what you think.
>>
>> Thank you,
>> Jan
--
Roberto Polli
Community Manager
Babel S.r.l. -
http://www.babel.it
T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.