You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Zakharov <al...@gmail.com> on 2006/09/15 14:56:20 UTC
[testing][beans] reverse engineering of RI
Hi all,
While investigating one of the failed tests from the beans module
(PersistenceDelegateTest#*) I have discovered that the test is doing a
reverse engineering in fact. It passes some worm-like object to public
API method and then analyzes the calling stacktrace of each of its
methods by means of
StackTraceElement[] eles = (new Throwable()).getStackTrace();
if (eles[i].getClassName().equals(…) && eles[i].getMethodName().equals(..)) {…}
In that way, to enable this test we need to rewrite our code and make
it identical to RI's (at least in respect to the stack trace). Such
testing technique may be applied to many parts of Java API, not only
beans. Of course I can imagine some user application doing this but
such people should probably know what they do.
Personally I don't like such methods of testing and vote for
refactoring of these tests. Other opinions? Thoughts?
Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by Andrew Zhang <zh...@gmail.com>.
On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Alexei Zakharov wrote:
> > Hi all,
> >
> > While investigating one of the failed tests from the beans module
> > (PersistenceDelegateTest#*) I have discovered that the test is doing a
> > reverse engineering in fact. It passes some worm-like object to public
> > API method and then analyzes the calling stacktrace of each of its
> > methods by means of
> >
> > StackTraceElement[] eles = (new Throwable()).getStackTrace();
> > if (eles[i].getClassName().equals(…) &&
> > eles[i].getMethodName().equals(..)) {…}
> >
> > In that way, to enable this test we need to rewrite our code and make
> > it identical to RI's (at least in respect to the stack trace). Such
> > testing technique may be applied to many parts of Java API, not only
> > beans. Of course I can imagine some user application doing this but
> > such people should probably know what they do.
> >
> > Personally I don't like such methods of testing and vote for
> > refactoring of these tests. Other opinions? Thoughts?
>
> That's insane. Does the Spec require a specific call sequence?
Maybe it wants to assert some methods are invoked. But the code is
unacceptable!
Sometimes, spec does point out or hint invoke one method would lead to
invoke another one. But instead of these reverse engineering codes, using
mock subclass and invoke flag could be a solution.
geir
>
> >
> > Thanks,
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [testing][beans] reverse engineering of RI
Posted by Alexei Zakharov <al...@gmail.com>.
> That's insane. Does the Spec require a specific call sequence?
Certainly not!
2006/9/15, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexei Zakharov wrote:
> > Hi all,
> >
> > While investigating one of the failed tests from the beans module
> > (PersistenceDelegateTest#*) I have discovered that the test is doing a
> > reverse engineering in fact. It passes some worm-like object to public
> > API method and then analyzes the calling stacktrace of each of its
> > methods by means of
> >
> > StackTraceElement[] eles = (new Throwable()).getStackTrace();
> > if (eles[i].getClassName().equals(…) &&
> > eles[i].getMethodName().equals(..)) {…}
> >
> > In that way, to enable this test we need to rewrite our code and make
> > it identical to RI's (at least in respect to the stack trace). Such
> > testing technique may be applied to many parts of Java API, not only
> > beans. Of course I can imagine some user application doing this but
> > such people should probably know what they do.
> >
> > Personally I don't like such methods of testing and vote for
> > refactoring of these tests. Other opinions? Thoughts?
>
> That's insane. Does the Spec require a specific call sequence?
>
> geir
>
> >
> > Thanks,
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Zakharov wrote:
> Hi all,
>
> While investigating one of the failed tests from the beans module
> (PersistenceDelegateTest#*) I have discovered that the test is doing a
> reverse engineering in fact. It passes some worm-like object to public
> API method and then analyzes the calling stacktrace of each of its
> methods by means of
>
> StackTraceElement[] eles = (new Throwable()).getStackTrace();
> if (eles[i].getClassName().equals(…) &&
> eles[i].getMethodName().equals(..)) {…}
>
> In that way, to enable this test we need to rewrite our code and make
> it identical to RI's (at least in respect to the stack trace). Such
> testing technique may be applied to many parts of Java API, not only
> beans. Of course I can imagine some user application doing this but
> such people should probably know what they do.
>
> Personally I don't like such methods of testing and vote for
> refactoring of these tests. Other opinions? Thoughts?
That's insane. Does the Spec require a specific call sequence?
geir
>
> Thanks,
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by Tim Ellison <t....@gmail.com>.
yuk! what is this test trying to achieve?
Tim
Alexei Zakharov wrote:
> Hi all,
>
> While investigating one of the failed tests from the beans module
> (PersistenceDelegateTest#*) I have discovered that the test is doing a
> reverse engineering in fact. It passes some worm-like object to public
> API method and then analyzes the calling stacktrace of each of its
> methods by means of
>
> StackTraceElement[] eles = (new Throwable()).getStackTrace();
> if (eles[i].getClassName().equals(…) &&
> eles[i].getMethodName().equals(..)) {…}
>
> In that way, to enable this test we need to rewrite our code and make
> it identical to RI's (at least in respect to the stack trace). Such
> testing technique may be applied to many parts of Java API, not only
> beans. Of course I can imagine some user application doing this but
> such people should probably know what they do.
>
> Personally I don't like such methods of testing and vote for
> refactoring of these tests. Other opinions? Thoughts?
>
> Thanks,
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by Andrew Zhang <zh...@gmail.com>.
On 9/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>
> Tim Ellison wrote:
> > yuk! what is this test trying to achieve?
>
> Andrew Zhang wrote:
> > OMG! what's the intention of such assertion?
>
> It seems that the original author of these tests aims to wrote as much
> code as possible. To have a nice monthly report may be - I don't know
> much details about BB life. And since the PersistenceDelegate test
> itself is a rather small class he probably decide that normal tests is
> not sufficient... :-)
aha......
Let's fix these codes which may bring troubles to Harmony, although the
montly report may look not as good as before. :-)
Regards,
>
> 2006/9/15, Andrew Zhang <zh...@gmail.com>:
> > On 9/15/06, Alexei Zakharov <al...@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > While investigating one of the failed tests from the beans module
> > > (PersistenceDelegateTest#*) I have discovered that the test is doing a
> > > reverse engineering in fact. It passes some worm-like object to public
> > > API method and then analyzes the calling stacktrace of each of its
> > > methods by means of
> > >
> > > StackTraceElement[] eles = (new Throwable()).getStackTrace();
> > > if (eles[i].getClassName().equals(…) &&
> > > eles[i].getMethodName().equals(..)) {…}
> >
> >
> > OMG! what's the intention of such assertion?
> >
> >
> > In that way, to enable this test we need to rewrite our code and make
> > > it identical to RI's (at least in respect to the stack trace). Such
> > > testing technique may be applied to many parts of Java API, not only
> > > beans. Of course I can imagine some user application doing this but
> > > such people should probably know what they do.
> > >
> > > Personally I don't like such methods of testing and vote for
> > > refactoring of these tests. Other opinions? Thoughts?
> >
> >
> > I strongly agree to refactor these tests!
> >
> > Thanks,
> > >
> > > --
> > > Alexei Zakharov,
> > > Intel Middleware Product Division
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [testing][beans] reverse engineering of RI
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Zakharov wrote:
> Tim Ellison wrote:
>> yuk! what is this test trying to achieve?
>
> Andrew Zhang wrote:
>> OMG! what's the intention of such assertion?
>
> It seems that the original author of these tests aims to wrote as much
> code as possible.
Now now... be nice... :)
To have a nice monthly report may be - I don't know
> much details about BB life. And since the PersistenceDelegate test
> itself is a rather small class he probably decide that normal tests is
> not sufficient... :-)
>
> Regards,
>
> 2006/9/15, Andrew Zhang <zh...@gmail.com>:
>> On 9/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > While investigating one of the failed tests from the beans module
>> > (PersistenceDelegateTest#*) I have discovered that the test is doing a
>> > reverse engineering in fact. It passes some worm-like object to public
>> > API method and then analyzes the calling stacktrace of each of its
>> > methods by means of
>> >
>> > StackTraceElement[] eles = (new Throwable()).getStackTrace();
>> > if (eles[i].getClassName().equals(…) &&
>> > eles[i].getMethodName().equals(..)) {…}
>>
>>
>> OMG! what's the intention of such assertion?
>>
>>
>> In that way, to enable this test we need to rewrite our code and make
>> > it identical to RI's (at least in respect to the stack trace). Such
>> > testing technique may be applied to many parts of Java API, not only
>> > beans. Of course I can imagine some user application doing this but
>> > such people should probably know what they do.
>> >
>> > Personally I don't like such methods of testing and vote for
>> > refactoring of these tests. Other opinions? Thoughts?
>>
>>
>> I strongly agree to refactor these tests!
>>
>> Thanks,
>> >
>> > --
>> > Alexei Zakharov,
>> > Intel Middleware Product Division
>> --
>> Andrew Zhang
>> China Software Development Lab, IBM
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by Alexei Zakharov <al...@gmail.com>.
Tim Ellison wrote:
> yuk! what is this test trying to achieve?
Andrew Zhang wrote:
> OMG! what's the intention of such assertion?
It seems that the original author of these tests aims to wrote as much
code as possible. To have a nice monthly report may be - I don't know
much details about BB life. And since the PersistenceDelegate test
itself is a rather small class he probably decide that normal tests is
not sufficient... :-)
Regards,
2006/9/15, Andrew Zhang <zh...@gmail.com>:
> On 9/15/06, Alexei Zakharov <al...@gmail.com> wrote:
> >
> > Hi all,
> >
> > While investigating one of the failed tests from the beans module
> > (PersistenceDelegateTest#*) I have discovered that the test is doing a
> > reverse engineering in fact. It passes some worm-like object to public
> > API method and then analyzes the calling stacktrace of each of its
> > methods by means of
> >
> > StackTraceElement[] eles = (new Throwable()).getStackTrace();
> > if (eles[i].getClassName().equals(…) &&
> > eles[i].getMethodName().equals(..)) {…}
>
>
> OMG! what's the intention of such assertion?
>
>
> In that way, to enable this test we need to rewrite our code and make
> > it identical to RI's (at least in respect to the stack trace). Such
> > testing technique may be applied to many parts of Java API, not only
> > beans. Of course I can imagine some user application doing this but
> > such people should probably know what they do.
> >
> > Personally I don't like such methods of testing and vote for
> > refactoring of these tests. Other opinions? Thoughts?
>
>
> I strongly agree to refactor these tests!
>
> Thanks,
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product Division
> --
> Andrew Zhang
> China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing][beans] reverse engineering of RI
Posted by Andrew Zhang <zh...@gmail.com>.
On 9/15/06, Alexei Zakharov <al...@gmail.com> wrote:
>
> Hi all,
>
> While investigating one of the failed tests from the beans module
> (PersistenceDelegateTest#*) I have discovered that the test is doing a
> reverse engineering in fact. It passes some worm-like object to public
> API method and then analyzes the calling stacktrace of each of its
> methods by means of
>
> StackTraceElement[] eles = (new Throwable()).getStackTrace();
> if (eles[i].getClassName().equals(…) &&
> eles[i].getMethodName().equals(..)) {…}
OMG! what's the intention of such assertion?
In that way, to enable this test we need to rewrite our code and make
> it identical to RI's (at least in respect to the stack trace). Such
> testing technique may be applied to many parts of Java API, not only
> beans. Of course I can imagine some user application doing this but
> such people should probably know what they do.
>
> Personally I don't like such methods of testing and vote for
> refactoring of these tests. Other opinions? Thoughts?
I strongly agree to refactor these tests!
Thanks,
>
> --
> Alexei Zakharov,
> Intel Middleware Product Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [testing][beans] reverse engineering of RI
Posted by Alexey Petrenko <al...@gmail.com>.
2006/9/15, Alexei Zakharov <al...@gmail.com>:
> Hi all,
>
> While investigating one of the failed tests from the beans module
> (PersistenceDelegateTest#*) I have discovered that the test is doing a
> reverse engineering in fact. It passes some worm-like object to public
> API method and then analyzes the calling stacktrace of each of its
> methods by means of
>
> StackTraceElement[] eles = (new Throwable()).getStackTrace();
> if (eles[i].getClassName().equals(…) && eles[i].getMethodName().equals(..)) {…}
>
> In that way, to enable this test we need to rewrite our code and make
> it identical to RI's (at least in respect to the stack trace). Such
> testing technique may be applied to many parts of Java API, not only
> beans. Of course I can imagine some user application doing this but
> such people should probably know what they do.
>
> Personally I don't like such methods of testing and vote for
> refactoring of these tests. Other opinions? Thoughts?
+1
>
> Thanks,
>
> --
> Alexei Zakharov,
> Intel Middleware Product Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division