On 9/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
