On 10/25/2013 11:38 AM, Roberto Polli wrote:
On Friday 25 October 2013 11:18:53 thierry bordaz wrote:
lib389/brooker.py:795: python variable naming convention: I would get
stick
with the "_" instead of camelCase and change whenever possible.
If you prefer to use '_' also for local variable, I am fine.
Using camel just for classes is more explicative, and I find that "_" are
easier to read and replace with sed ;)
tests/dsadmin_test.py: I renamed it lib389_test.py, you can merge my
changes tests/dsadmin_test.py:39: why remove the addbackend_harn?
Humm, to be honest... I do not know how to rename files :-)
git mv dsadmin_test.py lib389_test.py ;)
:-[ !! so easy :-D
tests/replica_test.py:119: you're using Backend.delete in a class that
should test just Replica. I would use harness and the standard
python-ldap methods in setup/teardown, so that we can change the Backend
and Replica class without at least breaking the tests.
I miss your point. It is calling in teardown conn.backend.delete, is
that the call that is not correct ?
That's just an IMHO: see those cases:
1- I change the Backend class and break the replica test: I'll look for errors
in Replica while the issue is in Backend
2- somebody works on the Backend class, I work on the Replica one: he can
break my tests.
Splitting the test stuff in an harness module will reduce the impact of all
that. As an example, I could even agree the setup process be done populating
entries via an LDIF. If I test Replica, Backend or Suffix I shouldn't have
other dependencies distracting me.
Is that related to Mock. For example in Replica, we need a suffix and a
replica but do not want to rely on them.
If instead of creating a real suffix/backend, we have mock of them we
could develop the replica tests without any concerns regarding further
changes in suffix/backend.
Is that your concern ?
regards
thierry
Let me know + Peace,
R.
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
