Envjs envjs

Comments and changes to this ticket

• You flagged this item as spam.
  

  gleneivey April 23rd, 2010 @ 08:07 AM

  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.

• You flagged this item as spam.
  

  gleneivey May 5th, 2010 @ 09:30 AM

  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?

• You flagged this item as spam.
  

  Steven Parkes May 5th, 2010 @ 12:12 PM

  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.