[dev] [commits] Horde branch master updated. 1e394986ba8dd83a6f2854f51c361f72fce9e7b5

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> I agree with Jan.  My mistake in trying to guess your original  
> motivation.  Obviously, the it would be great if all of our  
> framework packages (except 1 - see below) are usable outside of a  
> Horde application.
>
> The one exception is going to be the Core package.  This is the  
> place where all of the glue between Horde *application* and Horde  
> *framework* is going to go.  And with the recent changes that are  
> starting to make this separation a reality, one overriding thought  
> has come to mind: why do we even have a Core package?  It seems to  
> me that everything in Core should be moved to the horde application  
> package.  Is this the eventual goal?

I completely agree on Core being where the glue is, and on it not  
being useful outside of Horde apps. I would actually go the other way,  
in terms of moving more things to Core and having less of a Horde base  
application (and more of a core package + actual applications).

>>> One question concerning the unit tests: I added them because they  
>>> are  required to a certain degree by the project where I'm using  
>>> the  Horde_Notification package. I am however not 100% certain if  
>>> these  tests are useful to the Horde project. I see a tendency  
>>> towards  PHPUnit testing within Horde. But we are also ignoring  
>>> them to a  certain degree as we don't seem to care much if they  
>>> break. And I feel  that at that point unit tests may become more  
>>> of a nuisance rather  than being helpful.
>>
>> We rather need more tests than less. The fact that they break from  
>> time to time is probably due to us not having used tests that much  
>> in the past. We still have to get used to run them after each  
>> change. Some continuous integration would probably help too, but I  
>> don't see anyone having the resources at the moment to set this up.
>
> I would agree with the comment that test are good, but not  
> necessarily with the comment that more tests are better.  There can  
> be a problem with too many tests, and then you just run into the  
> issue of having to add additional maintenance costs for the test  
> code on top of the actual code.  There's a fine balance between  
> trying to test all permutations of the code vs. testing that you can  
> replicate a big-picture result.

Tests that don't add anything useful or that blindly assert every  
method just to have coverage aren't going to help us, no. But we do  
need to run the tests more, to set up continuous integration builds,  
and to have broader test coverage - by broader I mean across all  
packages, not all methods of a given package.

However sometimes exhaustive test suites seem appropriate - I've  
caught a lot of things in Horde_Db by copy-n-pasting tests across  
every adapter and trying to be as mind-numbingly thorough as possible.

> I'm not a tremendously big fan of PHPUnit from what I know about it  
> so far; it seems somewhat hackish to me - e.g. naming functions like  
> testTryingToDescribeAnEntireTestInA100CharacterFunctionNameUsingStudlyCapsIsNotTheMostClearWayToIdentifyAFailingTest.  Not sure if this is a limitation of PHPUnit or simply a case where we have not yet used all capabilities available in the package.  This makes determining what tests were failing a matter of bashing through a bunch of Exception-like text dumps.  Maybe I am simply using phpunit wrong - a wiki entry might be  
> useful.
>
> I just have to get into the habit of running the unit tests when  
> making a change.  This is something I admittedly need to become  
> better at.

There are output options to PHPUnit that make it easier to see what's  
going on, and for almost every assertion method there is an optional  
description parameter that can be passed to say something more than "x  
is not y" with a failure. Those might be helpful if I'm understanding  
your frustrations.

> Well... my ultimate desire is to remove Horde_Mobile entirely, and  
> possibly very soon.  It has been superseded (or will be superseded)  
> by Horde_View anyway - or whatever other output/template/view system  
> will eventually decide on.

I wouldn't mind seeing Horde_Mobile be hard-deprecated now, fwiw.

-chuck