ANT keeps on truckin' even if a major error occurs
-
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.
-
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?
-
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.
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.