s4: adding a DsdbTestCase class
nivanova at samba.org
Fri Nov 19 12:57:22 MST 2010
What you suggest is also a possible way, and it has the advantage that the
helpers could be used not only by the child classes.
I do not think these belong in the SamDB class though, it will become
crowded, and it mostly deals with, well, SAM :), and its methods are mostly
bound C functions.
However it appears the way things are usually done is to make a TestCase
subclass for the methods that are specific to a set of testsuites. Actually,
I do not believe it would lead to multiple inheritance if we are careful to
keep it sequential, and if we make sure that all the dsdb tests inherit the
same class, it would be less likely that people will start duplicating code
instead of just augmenting the parent class when necessary. It just seems
neater to me this way. Maybe we could combine both approaches...
Does anybody else have a suggestion or preference?
On Fri, Nov 19, 2010 at 9:13 PM, Kamen Mazdrashki <kamenim at samba.org> wrote:
> On Fri, Nov 19, 2010 at 17:48, Nadezhda Ivanova <nivanova at samba.org>
> > Hi Jelmer and team,
> > In the testsuites in dsdb/tests there is a practise currently that each
> > suite defines its own methods, even if they are the same as the ones used
> > other testsuites, such as delete_force, get_domain_sid and a few others.
> > avoid this, I suggest adding a DsdbTestCase class to samba.tests that
> > contains these methods, and all the testsuites that use them to inherit
> > as is the case with BlackboxTestCase and others. I have added the class
> > here:
> As previously discussed, I am not quite sure this is the right way
> wrap up those methods.
> Wrapping helpers in a TestCase classes will lead to a multiple
> inheritance pretty soon.
> What about implementing utility classes to wrap up methods?
> For instance:
> class DomainHelpers
> + init(SamDb)
> + get_sid
> + set_minPwdAge
> + dnsname
> class DirectoryService
> + init(SamDb)
> + set_dsheuristics
> + get_dsheuristics
> Other way may be to add those methods to SamDb class, but
> this will make it quite big and hard to read. (not to mention it is
> not good practice to have everything in just one place :)
> Kamen Mazdrashki
More information about the samba-technical