Actually, we can make this a lot easier by just going to the issue that Ray set up here: http://codereview.appspot.com/8894
If you could comment on the junit changes, that would be great. On Thu, Dec 4, 2008 at 4:40 PM, Joel Webber <[EMAIL PROTECTED]> wrote: > I've added tests to cover all the additional cases you describe, and it > looks like everything is working "as expected", assuming that by "as > expected" we mean "it's possible for one test to cause the next to fail if > it leaves a pending event around". I don't see any way around this that > doesn't involve a massive rearchitecture, and this problem has always > existed in one way or another. > > --- code review request --- > I've made the change I proposed earlier, in the attached patch. I added > some extra test cases to the manual JUnit tests in order to make sure we > don't screw this up in the future. Please ignore all the event triggering > stuff in there -- I needed it to be able to exercise the JUnit failure, but > can't commit it until I get the tests working properly. > > Branch: /releases/1.6 > Issue: 3167 > > On Wed, Dec 3, 2008 at 8:39 PM, Scott Blum <[EMAIL PROTECTED]> wrote: > >> On Wed, Dec 3, 2008 at 3:11 PM, Joel Webber <[EMAIL PROTECTED]> wrote: >> >>> So here are all the ways I can think of for a test method to complete, >>> either synchronously or asynchronously. Those not explicitly marked as such >>> work properly. >>> >>> Normal synchronous test methods: >>> - Test method completes successfully and synchronously. >>> - Test method triggers an exception synchronously (*not* from within an >>> event handler). >>> >>> Normal asynchronous test methods: >>> - Test method goes into async mode, returns, then passes (called >>> finishTest()). >>> - Test method goes into async mode, returns, then fails by triggering an >>> exception in an event handler. >>> - Test method goes into async mode, returns, then fails by timing out. >>> >>> Weird cases: >>> - Test method triggers an exception synchronously *from an event >>> handler*. >>> - As described above, the exception is thrown away from GWTTestCase's >>> onUncaughtException(). >>> - Test method completes synchronously, then triggers an exception between >>> test methods. >>> - Uncertain, but I believe it just throws away the exception, as in the >>> above case. >>> >> >> It would throw it away. This is kind of the weirdest case, because you've >> actually already reported a result for a case that you later discover >> failed, and you're waiting on an XHR to see what to run next. I suppose you >> could immediately fail the *next* test once it's ready with a >> PreviouslyFailedTestException. >> >> >>> - Test method completes [a]synchronously, then triggers an exception >>> during the next test method. >>> - The delayed exception causes the *next* test to report failure, which >>> seems somewhat wrong. >>> - But the stack trace still shows the actual point where the exception >>> occurred. >>> >>> What those last to "weird cases" lead me to believe is that we're not >>> really defending against anything by throwing away uncaught exceptions, and >>> that we should be able to allow all uncaught exceptions to 'fail' the >>> current test (even if it ends up being the wrong one). Are there any other >>> cases I'm missing here, or some subtle reason we can't do this? >>> >> >> This seems reasonable, I just wanted to enumerate the cases and make sure >> it makes sense. >> >> Other weird cases I can think of (there may be more): >> - Test method triggers an exception synchronously after setting up an >> async state >> - Test method triggers an exception synchronously *from an event >> handler* after setting up an async state (but before the method returns) >> - Test method triggers an exception synchronously *from an event handler*, >> then throws an exception itself synchronously. (We report a >> CaughtPlusUncaughtAtTheSameTimeException that contains both?) :) >> >> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
