[Building Sakai] [Management] MT deprecation recommendationsfor 2.7

Fri Mar 19 00:40:42 PDT 2010

Let's just be clear on one point:

It is not necessary to remove or even deprecate the static covers to enable unit testing for code. 

It may be necessary that the code which is being unit-tested does not use the static covers, but that is no obstacle to any other (non-unit-tested code, e.g.  local tools, 3rd-party code) continuing to use the static covers.

Regards
Stephen

>>> "Berg, Alan" <A.M.Berg at uva.nl> 3/19/2010 9:31 AM >>> 
Hi all,

I like Noahs email as debate is most welcome as QA hopes to motivate an increase test coverage.

> If someone had the
resources to write the tests, they would exist. The fractional cost to
switch off the covers is not why we don't have them.

Agreed

> I think the unit test scenario is a red herring.

Disagree.  If the MT agree to add tests as they maintain then we start to cluster and increase the regression testing around weak points. 

I am a great fan of unit like tests in combination with continuous builds. In Sakai 2.x if a bug is found I would promote the idea of adding tests around the cleaned code.If we run the builds say once every 2 hours with a praise mechanism then the community more aggressively avoids regression. I therefore think the current status of having limited test coverage is not an argument. I find David Haines suggestion of adding an extra method to get the instance in the cover rather intriguing and would enjoy more discussion. I also see Aarons point about ad-hoc improvement removing covers as code is maintained, as an incremental investment. 

Opinions?

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg

-----Original Message-----
From: sakai-dev-bounces at collab.sakaiproject.org on behalf of Noah Botimer
Sent: Thu 3/18/2010 22:42
To: markjnorton at earthlink.net
Cc: Developers Sakai-Dev
Subject: Re: [Building Sakai] [Management] MT deprecation recommendationsfor 2.7

My thoughts here are simple and brief. My solution:

1. Remove all usage of covers from "the release".

2. Mark everything about them deprecated.

3. Keep them synchronized until 2015 (i.e., forever).

4. Add a Maven profile to lint the code and yell if any usage creeps back
in.

5. Include a link in every file's Javadoc to a permanent page of
instructions on how to use the profile to scan and the alternatives for
contrib/local code.

6. Eat pizza with the money we save on not rewriting code.

Everybody wins.

I think the unit test scenario is a red herring. If someone had the
resources to write the tests, they would exist. The fractional cost to
switch off the covers is not why we don't have them. 

Thanks,
-Noah

On Thu, 18 Mar 2010 09:08:21 -0400, Mark Norton <markjnorton at earthlink.net>
wrote:
> Anthony Whyte wrote:
>> is it really all that challenging to add a service injection setter
>> method that relies on a bit of XML residing in a Spring bean
>> configuration file?
> For you and I - no.  For a Java developer familiar with Spring - 
> probably not.  However, I've  trained dozens of developers in Sakai tool 
> development who are NOT familiar with Spring or even the concept of 
> injection.  While admittedly a crude approach to solving the problem, 
> covers are considerably easier for non-Spring Java programmers, or 
> (perhaps more importantly) experienced non-Java programmers.
>> COMPROMISE PROPOSAL
>> I'd like to see static covers eventually removed (so +1) but recognize
>> that the current crowd wisdom appears to consider this desire, well,
>> unwise.  Still, I'd like to suggest a compromise proposal, one that
>> permits the removal of a static cover whenever it impedes the
>> implementation of unit tests written in support of a bug fix.
> What is the problem of writing unit tests and the presence of service 
> manager covers?  If the cover is a method duplicate of the service 
> manager, unit tests should work equally well for both (with the addition 
> of the getInstance() method).
>> Extension of 2.x unit test coverage is work that meets a long standing
>> yet largely unrealized goal of the Sakai Community.  Suspending such
work
>> because one finds a static cover in the way appears to me unwise.
>>   
> I'd like to understand how it is in the way.
> 
> - Mark
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to
sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

______________________________________________________________________________________________ 

UNIVERSITY OF CAPE TOWN 

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.

_____________________________________________________________________________________________________