Add more hacky q.delays
To work around the fact that we now do more trips around the event loop to update view state (because of going vis the store). Also add comment saying how horrible this is.pull/4209/head
parent
15d0bd9271
commit
8e288e14bf
|
@ -163,6 +163,13 @@ describe('joining a room', function () {
|
|||
}).then(() => {
|
||||
// wait for the join request to be made
|
||||
return q.delay(1);
|
||||
}).then(() => {
|
||||
// and again, because the state update has to go to the store and
|
||||
// then one dispatch within the store, then to the view
|
||||
// XXX: This is *super flaky*: a better way would be to declare
|
||||
// that we expect a certain state transition to happen, then wait
|
||||
// for that transition to occur.
|
||||
return q.delay(1);
|
||||
}).then(() => {
|
||||
// the roomview should now be loading
|
||||
expect(roomView.state.room).toBe(null);
|
||||
|
@ -177,6 +184,8 @@ describe('joining a room', function () {
|
|||
}).then(() => {
|
||||
httpBackend.verifyNoOutstandingExpectation();
|
||||
|
||||
return q.delay(1);
|
||||
}).then(() => {
|
||||
// We've joined, expect this to false
|
||||
expect(roomView.state.joining).toBe(false);
|
||||
|
||||
|
|
Loading…
Reference in New Issue