... I'm pretty sure using native async/await in your application code is what's making you sad
For two reasons -- one is that the code that runs after any await call will not be wrapped in a run loop because native promises aren't run loop aware, so anything after an await that uses the run loop, like calling .set on an Ember object, will trigger the auto-run assertion in tests
The other problem you're probably having is that your tests aren't waiting for any of the async behavior to happen
Ember.run(() => service.create(name)) doesn't wait for any actual async behavior -- it just drains the run loop queues
But your await calls will cause things to actually be async in the browser, and since your test isn't doing anything to wait for that behavior, it will end before all of your code has run
So you could try
await Ember.run(() => service.create(name))and I believe that would get the test to wait for the call to complete
But you're still vulnerable to the autorun assertion I mentioned before, so you probably want to turn those async functions into ember-concurrency tasks, which are runloop-aware
Boils down to when you feel like you should use native
asyncfunctions with Ember app code, you should ask yourself if said code needs to Ember runloop aware or not.