Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Unit Tests for Bug Fixes, New/Changed Functionality
From: Andreas Delmelle <andreas.delmelle@telenet.be>
In-Reply-To: <BLU436-SMTP935FE72911391A0876BAF5FBB30@phx.gbl>
Date: Fri, 11 Mar 2016 16:18:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4267816-6C19-4A92-BF72-B41413439606@telenet.be>
References: 
 <CACQ=j+d2Ny_N+6GcFbEd0FzxOSfXGPpC6T5NP2F0pyt_v9+_gQ@mail.gmail.com>
 <BLU436-SMTP935FE72911391A0876BAF5FBB30@phx.gbl>
To: general@xmlgraphics.apache.org

True enough, and I am definitely not against instating such a policy =
(quite on the contrary).
On the other hand, I do feel compelled to add a word of caution here.=20

Example:
Some people could be familiar enough with certain parts of the codebase =
to see what goes wrong and/or how a given issue can be fixed (or new =
functionality can be added), but do not have the appropriate experience =
with various testing frameworks in order to devise a test, nor do they =
always have the time available to familiarise themselves with that.
If I am working as an independent contractor for a client, and the =
hours/days can be invoiced to said client, it may be well worth it to =
spend double or triple the amount of time on coming up with test cases. =
If I look at it from a hobbyist perspective, and it is my own dime, I =
will probably be more inclined to leave writing the test cases to =
someone else.=20

So, a new potential problem becomes that certain patches will just =
remain uncommitted for a very, very long time, that is: as long as =
nobody finds the time or has the inspiration to come up with a way to =
formally and adequately test the fix or feature. Certain valuable fixes =
or new features may take ages to get committed if that policy is too =
strictly and blindly enforced (as in: no more commits without a test =
case, period).

All that said, summarised, some formal guidelines would definitely be a =
helpful and valuable start. Just keep in mind that with such a policy =
also comes a responsibility to either provide ideas and pointers to =
would-be committers, or complete the patches yourself, to get those gaps =
filled.=20


Cheers

Andreas

> On 09 Mar 2016, at 10:14, Chris Bowditch <bowditch_chris@hotmail.com> =
wrote:
>=20
> +1
>=20
> On 07/03/2016 19:52, Glenn Adams wrote:
>> I haven't kept an eye on whether or not bug fixes or new/changed
>> functionality is being committed with new junit tests; however, I =
have a
>> feeling this is not always done.
>>=20
>> We need to improve our coverage testing on XML Graphics projects,
>> especially w.r.t. to new code/fixes.
>>=20
>> I realize we don't have a formal project policy on this matter, but =
we need
>> to do a better job I think.
>>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org