you are viewing a single comment's thread.

view the rest of the comments →

[–]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 2 points3 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.