Formally, option #2 from my mail that was
> > 2. Remove PerformnceTest. Introduce a simple Logger that does not print by
> > default.
does not mix any performance *infrastructure* with junit testing.
I think that we do not have to find the final solution right now, we might see
various ideas as
[I got sick of the thread subject - it blended into every other JIRA
thread... ]
There is a 4th option - not mix performance infrastructure with unit
testing.
I'm all for getting "PerformanceTest" out of the class hierarchy, and
not having unit tests yammer out to console if we can avoid it.
To summarize, we have 3 options:
1. Keep PerformanceTest as a super class. Set printAllowed to false by default.
2. Remove PerformnceTest. Introduce a simple Logger that does not print by
default.
3. Move performance functionality to Decorator.
#1 is the most unliked. #3 as I wrote before does no
Mikhail Loenko wrote:
On 1/19/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Mikhail Loenko wrote:
The problem is unstable execution time of java programs:
If you consequently run the same java program on the same computer
in the same conditions, execution time may vary by 20% or even mor
On 1/19/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
> Mikhail Loenko wrote:
> > The problem is unstable execution time of java programs:
> >
> > If you consequently run the same java program on the same computer
> > in the same conditions, execution time may vary by 20% or even more
>
> Wh
Mikhail Loenko wrote:
The problem is unstable execution time of java programs:
If you consequently run the same java program on the same computer
in the same conditions, execution time may vary by 20% or even more
Why? Given that computers are pretty determinstic, I'd argue that you
don't
> [2] http://clarkware.com/software/JUnitPerf.html#howtouse
> ____________________
> George C. Harley
>
>
>
>
>
> Mikhail Loenko <[EMAIL PROTECTED]>
> 18/01/2006 17:06
> Please respond to
> harmony-dev@incubator.apache.org
>
>
>
tensions/RepeatedTest.html
[2] http://clarkware.com/software/JUnitPerf.html#howtouse
George C. Harley
Mikhail Loenko <[EMAIL PROTECTED]>
18/01/2006 17:06
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Commented: (HARMONY-
01/2006 12:57
> Please respond to
> harmony-dev@incubator.apache.org
>
>
> To
> harmony-dev@incubator.apache.org
> cc
>
> Subject
> Re: [jira] Commented: (HARMONY-31) Move peformance timing of unit tests
> into a decorator class.
>
>
>
>
>
>
>
e ?
Take care,
George
George C. Harley
Mikhail Loenko <[EMAIL PROTECTED]>
18/01/2006 12:57
Please respond to
harmony-dev@incubator.apache.org
To
harmony-dev@incubator.apache.org
cc
Subject
Re: [jira] Commented: (HARMONY-31) Move peformance timing of unit tests
into a decorator cla
Well, those messages were important for developers when
they were writing code and tests. Then tests came to repository 'as is'.
The messages are important to analyze failures also.
And the possibility to test perfromance is also important
For me any option that does not break functionality in fa
Absolutely right -- writing meaningful performance tests is hard.
Implementing your own Logger would not solve the problem though.
Best to avoid the 'This test worked OK' log messages altogether, and
stick to assertions.
Regards,
Tim
Mikhail Loenko wrote:
> It might be a problem...
>
> When we
It might be a problem...
When we use java.util.logging we do not just compare performance of security
API functions, the result is also depends on difference in performance of
java.util.logging in standard classes vs. Harmony classes. So if we use
non-trivial functionality from there then our resu
or something useful like log4j?
:)
geir
Tim Ellison wrote:
Why not use java.util.logging?
Regards,
Tim
Mikhail Loenko (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-31?page=comments#action_12362910 ]
Mikhail Loenko commented on HARMONY-31:
--
sounds reasonable...
Mikhail
On 1/17/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> neither is the Logger class -- so my point is if you are going to write
> some logging code why not do it in java.util.logging? You may choose to
> only do simple stubs for now until somebody steps up to do a real
neither is the Logger class -- so my point is if you are going to write
some logging code why not do it in java.util.logging? You may choose to
only do simple stubs for now until somebody steps up to do a real impl.
Regards,
Tim
Mikhail Loenko wrote:
> It's not yet implemented.
>
> thanks,
> Mi
It's not yet implemented.
thanks,
Mikhail
On 1/17/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Why not use java.util.logging?
>
> Regards,
> Tim
>
> Mikhail Loenko (JIRA) wrote:
> > [
> > http://issues.apache.org/jira/browse/HARMONY-31?page=comments#action_12362910
> > ]
> >
> > Mikhail Loe
Why not use java.util.logging?
Regards,
Tim
Mikhail Loenko (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/HARMONY-31?page=comments#action_12362910
> ]
>
> Mikhail Loenko commented on HARMONY-31:
> ---
>
> This is not what I meant.
>
> I was
[
http://issues.apache.org/jira/browse/HARMONY-31?page=comments#action_12362910 ]
Mikhail Loenko commented on HARMONY-31:
---
This is not what I meant.
I was going to create a Logger class at this point like this:
public class Logger {
public st
19 matches
Mail list logo
