r3809, for the specific case of an unnamed test object; that's the "earler
'review request: JUnit hang'" thread I mentioned. I got approval from Bob
for that one when I realized you were gone for the week, but left this one
on your queue 'cause it was lower-priority given the "front door" fix and
'cause you'd already started to opine about it.
I don't think we can prevent people from using the GWTTestCase default
constructor---I could dig into that, but presume that junit needs it or they
wouldn't provide it on TestCase(), since they have comments noting that is
"not for mere mortals" without setName()---but Miguel today suggested we
could update the Javadoc on GWTTestCase() to warn folks away. That's a good
idea, but at least with r3809 we fail-fast and mention that addTestSuite may
be what they meant to use.
So yes, we can and should and I think have fixed the underlying problem.
But the point to this patch is that if I found one way to wedge testing by
making recordResultsAndGetNextMethod() throw an exception, latent for
however many releases until Brian stepped in it, are there other ways to
provoke that? And can we not hang silently if there are?
On Mon, Oct 27, 2008 at 8:11 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
> Sorry for the delay. Shouldn't we fix the underlying problem, though?
>
>
> On Fri, Oct 17, 2008 at 1:49 PM, Freeland Abbott <
> [EMAIL PROTECTED]> wrote:
>
>> Scott, can you review-or-delegate both this and my earlier "review
>> request: JUnit hang"
>> I just sent a patch up to block sending a "bad Test" to the client (i.e.
>> to fail early if the test is unnamed), but that led me to thinking about the
>> more general how-not-to-hang-on-unspecified-error case.
>> We send the test to the client, it reports results, and if that fails
>> (i.e. because something's broke on the server), the client retries more or
>> less indefinitely. There's a timeout thread, of course, but that works by
>> reporting a timeout result... and so if the server can't record the result
>> (my unnamed test had that effect, for example), then the timeout-report also
>> gets retried, etc.
>>
>> This is a very corner case, and (I claim) not worth a whole lot of effort
>> to close, but we really ought to shutdown somehow, and send a message (as it
>> is, you can at least see server exceptions if you're -logLevel ALL, but in
>> default cases it just hangs silently). The issue is that we're in the RPC
>> handling of the client's result, so anything we throw gets caught and sent
>> back to the client, and the client needs to be stopped anyway. Being unable
>> to trust the server side framework (if I could trust it, we wouldn't have
>> gotten an exception!), I couldn't think of any way to get out gracefully
>> without more work than I thought it was worth, so ultimately I'm just
>> dumping output and calling System.exit(). A bit unfriendly to pull the rug
>> out from under JUnit, and I fear it still leaves the client dangling, but
>> again this is a squirrelly error case that I (because of my "front door"
>> closure) don't actually know how to trigger... I just wanted us not to hang
>> silently. Any suggestions on improvement are welcome!
>>
>>
>> Oh--if you want to test it, just make a test suite like so:
>>
>> import junit.framework.Test;
>> import junit.framework.TestSuite;
>>
>> public class AllTests {
>> public static Test suite() {
>> TestSuite suite = new TestSuite();
>> suite.addTest(new AnyGwtTestCaseYouLike()); // call ctor, not class
>> literal: oops!
>> return suite;
>> }
>> }
>>
>>
>>
>> (N.B. it looks like, in the class-literal processing, JUnit Tests contain
>> TestCases, and TestCases are what get made from each testable method. Has
>> GWTTestCase been the wrong abstraction all this while, and should have been
>> GWTTest?? Not that I propose changing it now....)
>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
