Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

ANT keeps on truckin' even if a major error occurs

#162

I just checked in bad code since ant kept going.
here's an example:
window-spec:

 [echo]
 [echo] Executing Window Spec 
 [java] [  Envjs/1.6 (Rhino; U; Mac OS X x86_64 10.6.3; en-US; rv:

1.7.0.rc2) Resig/20070309 PilotFish/1.2.0.11 ]

 [java]  TypeError: Cannot find function

_updateFormForNamedElement in object [object HTMLHeadingElement].
any hits on how to make this stop hard in this case?
thanks,
--nickg (meanwhile i will fix my code!)

Reported by nickg · April 22nd, 2010 @ 06:36 PM

State: new
Milestone: none
Assigned to: nobody

Activity

  1. gleneivey
    gleneivey

    I think that this is due to the way that env.js runs client code inside of try{} blocks. I think that this could be "fixed" fairly straight-forward-ly by throwing new exceptions when we catch them, but I don't want to make the change without a consensus on whether we want this behavior all the time or if we want a flag that we can set from tests.

    April 23rd, 2010 @ 08:07 AM

  2. gleneivey
    gleneivey

    Another problem I've seen in terms of qUnit failures not being detected/reported by Ant: if a test fails in between a "stop()" call and its following "start()" call, qUnit's test-reporting JavaScript doesn't run, so that number of asserts run isn't verified against expected(), and the RESULTS:/PASSED:/FAILED: summary lines aren't printed. Probably prohibitively difficult to fix within qUnit itself. Perhaps we need some wrapper that Ant can use to invoke each test and scan the results for the summary lines?

    May 5th, 2010 @ 09:30 AM

  3. Steven Parkes
    Steven Parkes

    I remember something like this from a long time ago. If memory serves, you can add a timeout to the stop call, which will cause qunit to automatically restart after the timeout.

    I also vaguely remember looked into making this defaultable so you didn't have to add to every stop.

    I've always thought it would be nice if we could trap errors in async callbacks like timers. I've wondered if it would be legit to call onerror in those cases, but in (limited) browser testing, it appears not.

    We could have an envjs-specific callback. Wouldn't work in the browser, but the point would be to make the test suite run well in the face of errors, which isn't supposed to be the steady state.

    May 5th, 2010 @ 12:12 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.