Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Fixed markup #383

FagnerMartinsBrack opened this Issue · 7 comments

4 participants


I've got into a situation where events are bound to certain element 'onDOMReady' without using delegate. I want to test some event behavior by triggering the event in the input.

I am not sure how wrong I am by relying on this kind of behavior, but I can't find another way around so:

  • I create a custom markup <div id="custom-markup"></div>.
  • Set the same #qunit-fixture styles.
  • Create the needed markup, let's say an input <input type="button" id="myInput" />
  • The event 'onDOMReady' binds a click event to the element
  • I create a custom resetMarkup to be called on each required teardown which resets the modifications that any test could be done in the HTML

With that use case in mind I would suggest a feature that:

  • Allows a custom markup (maybe #qunit-fixed) to be permanent (not to be removed as #qunit-fixture)
  • Allows this custom markup to be atomic and any event/modifications to be removed (except events set before the first module call)

Any thoughts?


I could be wrong, but afaik this is exactly what #qunit-fixture is for. It isn't removed it is reset to the original value after each test, and cleaned from any modifications, data store and event handlers.


Sounds exactly like #qunit-fixture to me, too.


I probably was not clear enough. What I meant is that #qunit-fixture maintain the DOM state but the events are removed.
A use case example:

Above we declare two bindings onDomReady and use two separate tests to check for each. The event is available to the first one, and for the second is not.
Again I am not sure if this is encouraged since unit test is not the same as behavior test (triggering events and comparing modifications). But if there is a #qunit-fixture which serves for a similar purpose I suppose it is.
Maybe if qunit-fixture use detach equivalent instead of relying on innerHTML this issue could be solved.


...and any event/modifications to be removed (except events set before the first module call).

There are no W3C interfaces to determine which events are attached to an element, so there is no way for QUnit to selectively remove events on your behalf. You have to track and manage events yourself.

There are plenty of ways to create an initial state for all tests including events. You could register a module setup callback that attaches events at the start of each test for example.



...There are plenty of ways to create an initial state for all tests including events

But still it would require to manually set the respective events for the test case instead of testing a single file behavior between the production and test environment (which is the desired goal).

Looks like due to the lack of support from the spec the solution for this would be manually reverting changes made into a given markup each time a test is run, so the original event would be maintained and we could avoid re-parsing the same JS again via ajax


If you use jQuery for events, this is taken care of automatically (through jQuery.clean and jQuery.remove). If you use a different library it might feature something similar, which you'd can then call from a hook in reset (no need to call it inside the test).

For vanilla DOM events however there is no way to unbind them, except by recreating the elements.

I'd recommend instead that you don't touch #qunit-fixture, instead touch elements inside of it. It is a reset' container, but the element itself is not reset, only its contents.

If you attach events to an element inside, that element will be recreated after each test and any past events will be gone / unreferenced / garbage collected.

Closing due to being impossible with the current DOM spec / browser support, and #qunit-fixture provides ways around this (by using a child instead).


Forgot to close...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.