Re: Need to contact rubygem-activesupport EPEL branch maintainer
https://bugzilla.redhat.com/show_bug.cgi?id=1127228 Try pinging on IRC or direct mail, I found he rarely (if ever?) responds to bugzilla spam. On 04/20/2015 08:27 AM, P J P wrote: Hello, Please see: - https://bugzilla.redhat.com/show_bug.cgi?id=1209124 Does anyone know where to contact Mr Michael Stahnke, the rubygem-activesupport EPEL branch maintainer. The package needs to be updated with few fixes. Thank you. --- Regards - P J P http://feedmug.com -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Contact info - Jeroen van Meeuwen (kanarip)
On 06.08.2014 23:28, Michael Stahnke wrote: snip Could you give me a list of packages with problems so I can do the second part? So the packages in question are: rubygem-actionmailer, rubygem-actionpack, rubygem-activerecord, rubygem-activeresource, rubygem-activesupport, rubygem-rails, rubygem-rack and rubygems. These are relevant bugzillas: https://bugzilla.redhat.com/show_bug.cgi?id=1115776 https://bugzilla.redhat.com/show_bug.cgi?id=1095129 https://bugzilla.redhat.com/show_bug.cgi?id=1095127 https://bugzilla.redhat.com/show_bug.cgi?id=1095125 https://bugzilla.redhat.com/show_bug.cgi?id=1095122 https://bugzilla.redhat.com/show_bug.cgi?id=1095120 https://bugzilla.redhat.com/show_bug.cgi?id=1095118 https://bugzilla.redhat.com/show_bug.cgi?id=961066 https://bugzilla.redhat.com/show_bug.cgi?id=948706 https://bugzilla.redhat.com/show_bug.cgi?id=924318 https://bugzilla.redhat.com/show_bug.cgi?id=924297 https://bugzilla.redhat.com/show_bug.cgi?id=905374 https://bugzilla.redhat.com/show_bug.cgi?id=905373 https://bugzilla.redhat.com/show_bug.cgi?id=891468 https://bugzilla.redhat.com/show_bug.cgi?id=847202 https://bugzilla.redhat.com/show_bug.cgi?id=843924 https://bugzilla.redhat.com/show_bug.cgi?id=831583 https://bugzilla.redhat.com/show_bug.cgi?id=731453 https://bugzilla.redhat.com/show_bug.cgi?id=731451 https://bugzilla.redhat.com/show_bug.cgi?id=731450 https://bugzilla.redhat.com/show_bug.cgi?id=677629 https://bugzilla.redhat.com/show_bug.cgi?id=1097205 https://bugzilla.redhat.com/show_bug.cgi?id=909088 https://bugzilla.redhat.com/show_bug.cgi?id=814725 https://bugzilla.redhat.com/show_bug.cgi?id=771152 https://bugzilla.redhat.com/show_bug.cgi?id=771151 Looks scary, but it the end it`s just rails, rubygems and rack. All of these are co-maintained with Michael Stahnke, which I have no luck contacting either. There are actually more unfixed vulnerabilities, but I am confident they can be fixed by more active maintainers. Hey, sorry for not getting some of these updated (you also didn't stay on #fedora-ruby long enough for me to respond). I find that updating many of these breaks API, because ruby library authors are really good at fixing security problems while introducing new issues. Many of them I didn't think I could update in EPEL -- for example moving rails from 2.x to 3.x is a HUGE change. Rubygems got rolled into ruby upstream - so the old rubygems isn't maintained upstream. Rack I should fix - they are good at compatibility. I also welcome any co-maintainers on these items. I used to use these packages lots from EPEL, at my current workplace I don't really. Thank you for the reply ! So this depends from one vulnerability to another, but in general we don`t necessarily have to (and according to EPEL guidelines we really shouldn`t) update to next major version just to fix the vulnerability. For example: https://bugzilla.redhat.com/show_bug.cgi?id=731450 is for Rails 2.x in EPEL 5, but backporting a fix (https://github.com/rails/rails/commit/bfc432574d0b141fd7fe759edfe9b6771dd306bd) is easy. So please respond to my mail from July and we can start working through these - I`m happy to help you with fix for each of these issues. Thanks ! -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Contact info - Jeroen van Meeuwen (kanarip)
Hello, following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kana...@kanarip.com. He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year. Thank you! -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Contact info - Jeroen van Meeuwen (kanarip)
On 06.08.2014 16:24, Stephen John Smoogen wrote: On 6 August 2014 10:53, Jan Rusnacko jrusn...@fedoraproject.org mailto:jrusn...@fedoraproject.org wrote: Hello, following the policy for nonresponsive maintainers, does anyone have a contact of Jeroen van Meeuwen (kanarip) ? All three mail addresses listed here http://fedoraproject.org/wiki/User:Kanarip bounce back, including FAS email kana...@kanarip.com mailto:kana...@kanarip.com. He is a co-maintainer of quite a number of packages (https://admin.fedoraproject.org/pkgdb/packager/kanarip/), which now have ~20 unfixed vulnerabilities combined in EPEL, some of them for over a year. I have run into kanarip and will have him correct the problems one way or another by the end of FLOCK. And I will get the EPEL items dealt with as soon as possible. Could you give me a list of packages with problems so I can do the second part? So the packages in question are: rubygem-actionmailer, rubygem-actionpack, rubygem-activerecord, rubygem-activeresource, rubygem-activesupport, rubygem-rails, rubygem-rack and rubygems. These are relevant bugzillas: https://bugzilla.redhat.com/show_bug.cgi?id=1115776 https://bugzilla.redhat.com/show_bug.cgi?id=1095129 https://bugzilla.redhat.com/show_bug.cgi?id=1095127 https://bugzilla.redhat.com/show_bug.cgi?id=1095125 https://bugzilla.redhat.com/show_bug.cgi?id=1095122 https://bugzilla.redhat.com/show_bug.cgi?id=1095120 https://bugzilla.redhat.com/show_bug.cgi?id=1095118 https://bugzilla.redhat.com/show_bug.cgi?id=961066 https://bugzilla.redhat.com/show_bug.cgi?id=948706 https://bugzilla.redhat.com/show_bug.cgi?id=924318 https://bugzilla.redhat.com/show_bug.cgi?id=924297 https://bugzilla.redhat.com/show_bug.cgi?id=905374 https://bugzilla.redhat.com/show_bug.cgi?id=905373 https://bugzilla.redhat.com/show_bug.cgi?id=891468 https://bugzilla.redhat.com/show_bug.cgi?id=847202 https://bugzilla.redhat.com/show_bug.cgi?id=843924 https://bugzilla.redhat.com/show_bug.cgi?id=831583 https://bugzilla.redhat.com/show_bug.cgi?id=731453 https://bugzilla.redhat.com/show_bug.cgi?id=731451 https://bugzilla.redhat.com/show_bug.cgi?id=731450 https://bugzilla.redhat.com/show_bug.cgi?id=677629 https://bugzilla.redhat.com/show_bug.cgi?id=1097205 https://bugzilla.redhat.com/show_bug.cgi?id=909088 https://bugzilla.redhat.com/show_bug.cgi?id=814725 https://bugzilla.redhat.com/show_bug.cgi?id=771152 https://bugzilla.redhat.com/show_bug.cgi?id=771151 Looks scary, but it the end it`s just rails, rubygems and rack. All of these are co-maintained with Michael Stahnke, which I have no luck contacting either. There are actually more unfixed vulnerabilities, but I am confident they can be fixed by more active maintainers. Thank you for helping out, really appreciated ! Thank You. Thank you! -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- Jan Rusnacko, Fedora Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Please review lib389 ticket 47578: removal of 'sudo' and absolute path in lib389
Hello Thierry, layout OK. As for tests - instead of reinventing the wheel by defing class Test_standAlone to set up instance, use py.test fixture. Also, you should not force setup, test, teardown execution for each test by specifying sub-methods for each test. Testing framework (py.test) should be doing that. I think this will make your tests fail badly if some exception occurs - if _test_ticket47560_setup raises exception, it will propagate back to py.test and cleanup method will never be executed for that ticket. Also, I believe each ticket should have its own file which contains one or more testcases. I think that would reasonably group relevant things together. On 10/30/2013 05:57 PM, thierry bordaz wrote: https://fedorahosted.org/389/attachment/ticket/47578/0001-Ticket-47578-CI-tests-removal-of-sudo-and-absolute-p.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Proof of concept: mocking DS in lib389
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 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Proof of concept: mocking DS in lib389
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 : 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Proof of concept: mocking DS in lib389
On 10/29/2013 03:30 PM, thierry bordaz wrote:
On 10/29/2013 02:18 PM, 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 :)
Hi Jan,
Sorry my question was not clear. For example an other approach could be
Class DSInstance (object):
def __init__(self):
...
def ldapadd_r(self, input):
# real call to pythonldap.add_s
Class MockDSInstance(DSInstance):
def __init__(self):
...
def ldapadd_r(self, input):
input = input.strip()
entry = dict(e.strip().split(': ') for e in input.split('\n'))
self.dit[entry['dn']] = entry
My understanding is that both approach would allow us to call inherited
methods, just ldap method are different.
What are the advantages of the approach you described compare to the one
above ?
Oh, ok. Not sure what would be advantage/disadvantage. Result of both approaches
is basically the same ... We could do it this way too.
best regards
thierry
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
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Proof of concept: mocking DS in lib389
On 10/28/2013 02:31 PM, Rich Megginson wrote: On 10/26/2013 12:49 AM, Jan Rusnacko wrote: On 10/25/2013 11:00 PM, Rich Megginson wrote: On 10/25/2013 01: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. def test_add_repl_manager(fake_ds_inst_with_repl): ds_inst = fake_ds_inst_with_repl ds_inst.repl.add_repl_manager(cn=replication manager, cn=config, Secret123) assert ds_inst.dit[cn=replication manager, cn=config][userPassword] == Secret123 assert ds_inst.dit[cn=replication manager, cn=config][nsIdleTimeout] == 0 assert ds_inst.dit[cn=replication manager, cn=config][cn] == replication manager If you are using a real directory server instance, doing add_repl_manager() is going to make a real LDAP ADD request, right? Correct. If you pass DS with real ldapadd method that makes real reqests, its going to use that. Will it still update the ds_inst.dit dict? ds_inst.dit is updated in mocked ldapadd. So in real ldapadd, no. Wouldn't you have to do a real LDAP Search request to get the actual values? Yes, correct. ds_inst.dit[] .. call is specific to mocked DS. But you are right - I could add fake ldapsearch method, that would return entries from 'dit' dictionary and use that to retrieve entries from mocked DS. Because, otherwise, you have separate tests for mock DS and real DS? Or perhaps I'm missing something? I dont understand the question, but let me answer something :) Class DSInstance would have ~10 methods that make real requests to real DS instance (setup, remove, ldapadd, ldapmodify, .., start, stop ..). All other methods would probably depend on ldapadd, ldapmodify.. We can tests these 10 methods either using real DS, or somehow faking the traffic, or just review them manually .. As for other 95 % of library functions that depend on those, we can use MockDS with fake ldapadd, ldapmodify to make unit tests. These unit tests will verify that *assuming* they receive OK ldapmodify method, they will use it to perform correct calls to set up the thing they are supposed to. To be concrete, unit test above, test_add_repl_manager(fake_ds_inst_with_repl), verifies that method ds_inst.repl.add_repl_manager() will add replication manager with expected fields using ldapadd method of object that was passed to it. It will *not* verify the correctness of ldapadd method of real DSInstance class (that is the job of ldapadd`s unit test), nor will it verify that real DS instance would accept such call or behave correctly (that is the job of DS acceptance tests). Hence, a unit test. 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 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Proof of concept: mocking DS in lib389
On 10/25/2013 11:00 PM, Rich Megginson wrote: On 10/25/2013 01: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. def test_add_repl_manager(fake_ds_inst_with_repl): ds_inst = fake_ds_inst_with_repl ds_inst.repl.add_repl_manager(cn=replication manager, cn=config, Secret123) assert ds_inst.dit[cn=replication manager, cn=config][userPassword] == Secret123 assert ds_inst.dit[cn=replication manager, cn=config][nsIdleTimeout] == 0 assert ds_inst.dit[cn=replication manager, cn=config][cn] == replication manager If you are using a real directory server instance, doing add_repl_manager() is going to make a real LDAP ADD request, right? Correct. If you pass DS with real ldapadd method that makes real reqests, its going to use that. Will it still update the ds_inst.dit dict? ds_inst.dit is updated in mocked ldapadd. So in real ldapadd, no. Wouldn't you have to do a real LDAP Search request to get the actual values? Yes, correct. ds_inst.dit[] .. call is specific to mocked DS. But you are right - I could add fake ldapsearch method, that would return entries from 'dit' dictionary and use that to retrieve entries from mocked DS. 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 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Proof of concept: mocking DS in lib389
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 proof_of_concept_mocking.tar.gz Description: GNU Zip compressed data -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: Ticket #47558 Implement ModuleProxy for lib389
https://fedorahosted.org/389/ticket/47558 https://fedorahosted.org/389/attachment/ticket/47558/0001-Initial-commit-with-DSModuleProxy.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
