s4member environment and 'useless' tests

[Andrew Bartlett]

On Tue, 2017-01-10 at 21:55 +0000, Rowland Penny wrote:
> 
> 
> Yes. Openchange seems to have died, so you are proposing to keep test
> code around for a dead project, just in case it re-animates itself ?

For now, yes.  It isn't a large burden.

> Also, just in case you haven't noticed, I am only proposing removing
> test code, I haven't proposed removing any 'C' code, just python &
> perl.

My point exactly.  We should not remove the tests for which there is
code.  I don't feel like removing that code just yet, but I am happy if
we consolidate the test environments.

> > 
> > It also tests, alongside rpc_proxy, the python domain-join code (an
> > alternative to the C based code in 'net').
> 
> Then the test needs to be pointed at an AD DC joined to a test
> domain,
> this is what we need to be sure works.

I'm not sure what you mean here.  s4member and rpc_proxy are pointed at
an AD DC.

> > 
> > I would be much more convinced if the tests of this environment
> > were
> > blocking code development, or they take a long time, but removing
> > them
> > *because they found an actual bug* seems a bit strange.
> 
> The problem, as far as a understood it, was that a test against
> 's4member' was failing, I asked why we were doing this and Michael
> Adam said 'Agreed. Let's remove it...' , so I created the patches.

Removing a failing test because it is failing, without understanding
why it failed and why that change is acceptable is just sweeping the
issue under the carpet.  

> > I am happy if s4member and rpc_proxy are combined, but given the
> > changes I did in da3a79831afbd1b85592be36eb47de375e575643 to make
> > it
> > work, I'm not sure if the two are compatible.
> > 
> > Andrew Bartlett
> > 
> 
> Can I be blunt, just what do you have against removing old, no longer
> really useful code ? Tests should be relevant, even if it means
> writing
> new tests. 

You and I have different ideas of old, and no longer really useful. 
That seems to be the base of our disagreement.  

That isn't entirely un-reasonable: your primary work is with our users,
and we steer our users clear of some areas of the codebase.  That is
important actually, because allows those of us doing development the
latitude to remove those things without pain in the future.  

I doubt this resolves our disagreement, but I hope it clarifies things
a little.

Andrew Bartlett