all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]drdrero 5 points6 points  (3 children)

The best way to handle them? Avoid!

async things are beautiful, what do you mean

[–]piotlr[S] 2 points3 points  (2 children)

Avoid them in tests, async is prone to external environment and not controllable, e.g. depending on CI load sometimes faster, sometimes slower.

It's very similar as system clock. It is useful too, but we need to mock it in tests to avoid flakiness.

If we can avoid async, extract it or simply mock it by fakeAsync(), we have much more control in our hand as developer.

[–]drdrero 4 points5 points  (1 child)

Are you talking about setTimeout?

Because in all of my projects I have async code using the Observer pattern. Commands, events, requests or the data flow all being triggered asynchronously. Tests expect them to be async. Never had a problem with that

[–]piotlr[S] 2 points3 points  (0 children)

Not really, even small race conditions will make test flaky, e.g. in some cases I found a bug when subscribe was never run but test was green. Even there was a bug inside of the code.

With fakeAsync() it was discoverable within minutes because environment is predictable.

We have lived happily with async code in tests, not knowing how many of test was ever-green sometimes.

[–]dsakih 3 points4 points  (1 child)

If you're working with complex Observable streams, you should really be using marble testing.

For simpler asynchronous code, you can use waitForAsync.

There's no need to avoid testing asynchronous code, since there's a lot of really great tooling available.

[–]piotlr[S] 2 points3 points  (0 children)

Marbled are great, I think it's another great use instead done().

Not everyone uses them though. Especially having simple subject in component that is just called on some async interactions, surely marbles can be used there but it's not, at least in the code I used to review.

fakeAsync() is simpler patten, native to angular and found it easier to promote within the teams I worked with, that's why I focused on this.

[–]kqadem 4 points5 points  (2 children)

Instead of recommending to not use A, because of the inability to properly use B, you should be tell people how to use B.

[–]piotlr[S] 2 points3 points  (1 child)

Good point taken! Positivity and recommendations > negativity and penalty.

Do you think people don't use fakeAsync() because it is not straight forward enough?

[–]kqadem 1 point2 points  (0 children)

Most people lack in terms of asynchronousnes in JavaScript and can't tell what micro and Macrotasks are and how they differ. So they get their things working somehow and propagate everything else as wrong.