walter · May 22, 2018 21:25 · May 22, 2018
diff --git a/ember-slack-bendemboski-async-gotchas.md b/ember-slack-bendemboski-async-gotchas.md
@@ -0,0 +1,18 @@
+## From @bendemboski Ember Community Slack -testing channel
+[link](https://embercommunity.slack.com/messages/C045C9ABM/convo/C045C9ABM-1527023821.000621/)
+
+... 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
+
+```JavaScript
+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