Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates
 66.249.92.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=dxXHAyi42o4M1Zu1F+wQbvtvfHiIf1qJjaBdUpRzlUQxKdRuB49sCnZEFiV4PuUxSdc7wZ5fSWWlFmpEmzO942HNghY8wHQ7gS6N8Pn3ZI5NzA5sk3nDhzoWeN+ivoRZkMY6t7yD6vcbAAGUfdKbKK4fhIlK/QAG5PovlObOHiU=
Message-ID: <906dd82e0601250348p7bb5a17bgd30c59b1aced745d@mail.gmail.com>
Date: Wed, 25 Jan 2006 17:48:03 +0600
From: Mikhail Loenko <mloenko@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Unit and performance testing
In-Reply-To: <46d21a9a0601250204x4bc129f8u69940700d3522ae2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <906dd82e0601232340n5de6f561v8bb6db7ac4756f1c@mail.gmail.com>
	 <43D60A4A.7030107@gmail.com>
	 <906dd82e0601240421v507ecc43x75b4d42cd728def7@mail.gmail.com>
	 <43D74548.3020301@gmail.com>
	 <46d21a9a0601250204x4bc129f8u69940700d3522ae2@mail.gmail.com>

One more reason when logs are necessary:

If testing is possible in some configurations only
(like set of providers contains something or default encoding is ...), then
1) build failing in all different configs would be annoying
2) One has to be able to scan logs for warnings to verify that
functionality is tested
when the config is as expected

A different exit status for the tests that can test in the given
configuration would
help.

Thanks,
Mikhail

On 1/25/06, Anton Avtamonov <anton.avtamonov@gmail.com> wrote:
> On 1/25/06, Thorbj=F8rn Ravn Andersen <thunderaxiom@gmail.com> wrote:
> > Mikhail Loenko wrote:
> >
> > > fail() is not always convinient, for example, how would you print
> > >
> > >stack trace to fail()? Meanwhile stacktrace is most often enough
> > >
> > >
> > If you need a stacktrace, why not just throw a RuntimeException at that
> > point?  JUnit will then include the stack trace in the report.
> >
> > --
> > Thorbj=F8rn
> >
>
> Absolutely agree
> As I know 'standard' test case signature is:
>
> public void testSomeTestName() throws Exception {
> }
>
> So that all checked and runtime exceptions are passed directly to
> JUnit framework (which properly logs them).
>
> I do beleive logging is very useful feature. However I think that the
> preferrable place to do logging is code rather than tests. JUnit
> provides lots of fucntionality to write well-documented tests and we
> don't have to add extra-code for logging (which obviously made test
> cases longer and harder for understanding).
>
> I beleive the right place to use logging are try/catch sections where
> catch does nothing (the most ususal case), so that we just silently
> ignore some error situations. Having logs there will allow us to
> understand the system execution paths and what was going wrong and
> where. For such purpose different logging levels work really fine.
>
> --
> Anton Avtamonov,
> Intel Managed Runtime Division
>