Hey Scott, Sorry for not responding right away, swamped at work. The main idea behind Hiro is to run each suite in a separate environment, isolated from all others including the global scope.
At DISQUS we had our JavaScript tests written using QUnit and the problem was with global state of the widget itself. Let say, you are testing an internal event system and you have a suite that removes default listeners to make sure that it is possible. However, other tests rely on those listeners so once they are removed in the global scope, it breaks other tests. As another example, consider regression tests. A few months ago we found out that Prototype.js 1.5 was breaking our JSON parser implementation (because they were overwriting Object.toJSON). We fixed that bug but we also wanted to add a regression test to make sure it won't happen again. And with shared global space in QUnit that means that we have to manually load specific version of Prototype.js before each test that needs it and clean up after. That started to get messy so I decided to take another approach. Hiro creates an iframe and loads your fixture into it before each test suite (initially I implemented it on a per-test basis but it can be really slow). Then it runs all the tests and passes shortcuts to the sandboxed `window` and `document` objects into them. And after the suite is done, it simply removes the iframe. So with Hiro each suite has its own clean environment and there is no global scope polution. Anton On Monday, June 13, 2011 at 6:34 PM, Scott Sauyet wrote: > Anton Kovalyov wrote: > > I've written a tiny unit testing framework named Hiro that runs suites in > > separate iframe sandboxes. Another neat feature (in my opinion) is that > > library's code doesn't make any assumptions about its presentation, it just > > triggers a bunch of events. Any code can listen to them and render the > > report in any form they wish. As an example, you can take a look at web.js > > (http://web.js) file in the same repository that implements the default UI > > for Hiro. > > > > Anyway, I'd really appreciate if people here could find time to review the > > library and its code (hiro.js has about 520 LOC) and make any comments on > > it. > > > > * Hiro's website:http://hirojs.com/ > > * GitHub > > repo:https://github.com/antonkovalyov/hiro/(https://github.com/antonkovalyov/hiro/blob/master/hiro.js) > > Can you explain a little more of the rationale behind this. Is this a > personal exercise? Is there something that the big players (QUnit, > JSUnit, YUI Test, JsTestDriver) aren't supplying that this can do for > us? It's a nice idea to separate the rendering from the testing; but > is that the only differentiator? Or that and the suite mixin? > > -- Scott > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]) -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
