Teardown with App.destroy

[theworkerant]

I've been searching like crazy to nail down this bug, and I think it has to do with qunit setup/teardown.

Loading some embedded records (Responses) on my Entry model like this:

    setup: ->
      App         = startApp()
      store       = App.__container__.lookup("store:main")
      controller  = @subject()

      Ember.run ->
        store.pushPayload "entry", entryFixture
        controller.set('model', store.find('entry', entryFixture.entry.id))

    teardown: -> Ember.run(App, App.destroy)

And it works fine running a single test, but on running whole suite the first one passes then I get the following:

Setup failed on Generates #sections from catalog_definitions: Assertion Failed: Expected an object as `data` in a call to `push`/`update` for flaredown@model:response: , but was <flaredown@model:response::ember387:hbi_general_wellbeing_fd088f9929639fd742a209b4b083c421>
Source:     
Error: Assertion Failed: Expected an object as `data` in a call to `push`/`update` for flaredown@model:response: , but was <flaredown@model:response::ember387:hbi_general_wellbeing_fd088f9929639fd742a209b4b083c421>
    at new Error (native)
    at Error.EmberError (http://localhost:4300/assets/vendor.js:27425:23)
    at Object.Ember.assert (http://localhost:4300/assets/vendor.js:17039:15)
    at Ember.Object.extend.push (http://localhost:4300/assets/vendor.js:75059:15)
    at http://localhost:4300/assets/vendor.js:66195:15
    at Array.forEach (native)
    at forEach (http://localhost:4300/assets/vendor.js:27206:32)
    at extractEmbeddedHasMany (http://localhost:4300/assets/vendor.js:66193:7)
    at http://localhost:4300/assets/vendor.js:66172:15
    at http://localhost:4300/assets/vendor.js:73146:20

It seems Ember.run(App, App.destroy) is not sufficient reset the test environment back to zero? What else might need to happen here?

[theworkerant]

Possible duplicate: #83

[theworkerant]

Running into this more and more, seems related to Ember runloop. Tests pass when run individually but it seems that if the runloop isn't done when Ember.run(App, App.destroy) is called, it pollutes the next tests in a group, causing them to fail.

Any suggestions on how to confirm/solve this would be lovely.

[topaxi]

I just ran into the same issue, any way to fix this or usable workaround?

My test looks very very similar to the one above.

Edit: Nevermind, got my case fixed by running andThen after Ember.run in my testcase :)

[MichaelVdheeren]

Having the same problem :-(

[Chun-Yang]

One dirty way to get around this is using Ember.run.later to delay the destroy. I created an async helper to do this.

// tests/helpers/start-app.js
Ember.Test.registerAsyncHelper('andLater',
  function(app, callback, timeout) {
    Ember.run(function() {
      Ember.run.later(function() {
        callback();
      }, timeout || 500);
    });
  }
);

Try to call andLater at the end of your test.

[rwjblue]

I need a test case that demonstrates the problem to figure out what is happening and fix it.

Can someone make a simple demo project that I could look at?

[MichaelVdheeren]

@rwjblue By now I've managed to fix this. In our case (as in most cases I believe) it had to do with promises not passing or setting attributes on objects that have been destroyed.

What I did:

• go over any jQuery stuff in the app and make sure you unbind any bound event before the view is destroyed. If binding to an event (like bootstrap modal shown) and setting an attribute in that function, use an Ember.run.
• look for any code that finds/fetches models async and where you do not use the model handler of the route. If you have a .then on that find/fetch containing any attribute sets or gets make sure the object is not destroyed by checking isDestroying and isDestroyed.

[fsmanuel]

Similar to @Chun-Yang i added a helper function https://github.com/rwjblue/ember-qunit/issues/83#issuecomment-95990645

[piotrpalek]

@rwjblue I might have the same problem: http://emberjs.jsbin.com/mezinu/7/edit?html,css,js,output
not sure if this is the same bug that is affecting @theworkerant

edit: I might add that if I replace the click's with fillIn's (to fill in the input in both tests) the tests will pass (what I mean by pass is that the "some resource" text will not be rendered twice).

edit2: Ok this is probably not the same bug because my jsbin works when I try ember 1.10:
http://emberjs.jsbin.com/mezinu/9/edit?html,css,js,output

seems I found a regression, added it as a seperate issue here: https://github.com/rwjblue/ember-qunit/issues/166

[gitjeff05]

@Chun-Yang What do you call andLater() with? What do you pass as the callback?

[Chun-Yang]

@gitjeff05 In mocha, you have done. I use

andLater(done);

For qunit, I guess there is something equivalent.

[timohermans]

I'm still having this issue.

Properties on a controller that are being set in test #1 are still present in test #2. The Ember.run.later solution in the teardown doesn't work for me unfortunately.

[alvinvogelzang]

I experience exactly the same issue as @temo44. Also tried the ember.run.later but I'm not sure what to pass in as a callback.

[alvinvogelzang]

@temo44 if your properties are arrays you can probably solve it by clearing them in init like:

  init: function() {
    this.listing = [];
  }

That solved it for me: emberjs/ember.js#10255

[timohermans]

@alvinvogelzang Thanks for the suggestion. This was indeed how we fixed it in our application, except we did in the setupController hook. Thanks!

[atomkirk]

THANK YOU! init solved the problem for me too. @rwjblue I can imagine that this is a hard bug to figure out whats going wrong. I think I could get permission to share our source with you, pointing the backend at my machine with ngrok or something so you can run this test module and debug it yourself. I'm in the slack group @atomkirk

[atomkirk]

Ok, I think I've got a little more insight to add here. Turns out my problem was default properties on services not being reset between tests. For example, I have this service:

import Ember from 'ember';

export default Ember.Service.extend({

  items: [], // originally, I only had this without resetting it in `init`

  init() {
    this._super(...arguments)
    this.set('items', [])
  },
})

Once I explicitly reset items to [] in init it worked. So it appears the service is being reused between tests?

[hadsy]

Hey @atomkirk, here is a useful link describing the shared state issue when using arrays. https://dockyard.com/blog/2015/09/18/ember-best-practices-avoid-leaking-state-into-factories

We had similar issues with tests and moved all array initialisation in to init()

[trentmwillis]

Looks like this issue has been resolved, so I'm going to close this issue.

[atomkirk]

You dont think its a bit odd that all the apps objects arent being destroyed between tests? Is this as designed?

[rwjblue]

@atomkirk - It isn't about destruction at all actually. Your snippet:

export default Ember.Service.extend({
  items: []
});

Is literally putting an array on the prototype of that service. The equivalent (in plain JS) is the following:

function SomeService() {}
SomeService.prototype.items = [];

This will be shared with all instances that you create. There is no way for Ember, ember-qunit, or any other thing (other than the garbage collector I suppose) to clear that array.

[atomkirk]

I figured if the app was destroyed and recreated between every test even the prototypes were being destroyed and recreated. For example, if I set window.AppName = null Between tests it still happens. Which shows I don't understand how it works.

Edit: Nevermind, it clicked.

The browser loads this into memory as definitions/instructions:

Ember.Object.extend({ items: [] })

And then at runtime, when the app is created and run, it creates instances in memory:

Ember.Object.create({ items: [] })

[RustyToms]

@rwjblue ( 🍺 ) explained this to me for a very similar question a couple of years ago. It still trips me up, and everyone else on my team every once in a while. If you are going to be frustrated by this, be frustrated by javascript, not Ember 😄
emberjs/ember.js#10255