tl;dr
In almost all cases, they can be used interchangeably, but using fakeAsync()/tick() combo is preferred unless you need to make an XHR call, in which case you MUST use async()/whenStable() combo, as fakeAsync() does not support XHR calls.
For the most part they can be used interchangeably. I can’t think of anything off the top of my head in which one is required over the other, except for the case of components whose external templates and styles are not compiled inline in to the component for testing (i.e. using SystemJS). When using SystemJS, XHR calls are made for the external templates and styles. fakeAsync() cannot be used when there are XHR calls made. On the other hand, when using Webpack, the external templates and styles get compiled inline, so you can use fakeAsync().
Other than that, I think it’s a matter of style preference. One thing I can say is imagine you need to make multiple calls that are asynchronous, like in this example. You need nested fixture.whenStable() calls, which can start to look to pretty ugly when they get so deep.
someAsyncAction();
fixture.whenStable().then(() => {
fixture.detectChanges();
expect(something)
changeSomethingElseAsynchronously();
fixture.whenStable().then(() => {
fixture.detectChanges();
expect(something);
anotherAsyncAction();
fixture.whenStable().then(() => {
fixture.detectChanges()
expect(somthingeElse)
})
})
})
This might look cleaner (and easier to reason about) without all those fixture.whenStable()s and code that looks synchronous.
tick();
fixture.detectChanges();
expect(something)
changeSomethingAsynchronously()
tick();
fixture.detectChanges();
expect(somethingElse)
changeSomethingAsynchronously()
tick();
fixture.detectChanges();
expect(somethingElse);
Another thing I might add is the OCD part of me always needs to check that my calls in the fixture.whenStable() is called
fixture.whenStable().then(() => {
expect(...)
console.log('called...')
})
Imagine that you forgot to wrap the test in async. Without that, the test will complete before the fixture.whenStable resolution, and you will never know it. It will look like the test passed, which is a false positive. What actually happened is that the assertion was never even called.
For this reason, I’ve actually been moving away from async. But if you like that style, and trust yourself that you always wrap the test in async, then stick with it. But with fakeAsync, everything is called synchronously, so there’s no chance of the assertion not being called.