This isn't only when doing integration testing. Testing view- and binding- related code has to use these helpers, too (for example, "unit" testing components). It *may* be that the idea of unit and integration testing isn't actually that appropriate as an idea for Ember and other client-side frameworks?

Either way, I think we should add some more text here about the nature of testing web applications. Something akin to this:

"One of the major issues in testing web applications is that all code is event-driven, therefore has the potential to be asynchronous (ie output can happen out of sequence from input). This has the ramification that code can be executed in any order.

An example may help here: Let's say a user clicks two buttons, one after another and both load data from different servers. They take different times to respond.

When writing your tests, you need to be keenly aware of the fact that you cannot be sure that the response will return immediately after you make your requests, therefore your assertion code (the "tester") needs to wait for the thing being tested (the "testee") to be in a synchronized state. In the example above, that would be when both servers have responded and the test code can go about its business checking the data (whether it is mock data, or real data).

This is why all Ember's test helpers are wrapped in code that ensures Ember is back in a synchronized state when it makes its assertions. It saves you from having to wrap everything in code that does that, and it makes it easier to read your tests because there's less boilerplate in them"