Angular 测试中的 fakeAsync 和 async 有什么区别? [英] What is the difference between fakeAsync and async in Angular testing?

问题描述

我知道 tick() 函数使用 fakeAsync().我也可以将 fixture.whenStable().then() 与 async() 和 fakeAsync() 一起使用.

I know that tick() function utilizes fakeAsync(). And also I can use fixture.whenStable().then() with async() and fakeAsync() as well.

我想知道它们的确切用例.谁能用例子解释一下.

I want to know the exact use case for both of them. Can anyone explain this with examples.

注意:我想在这两种情况下都使用 Fake Service 或 Stub.

推荐答案

tl;dr

在几乎所有情况下，它们都可以互换使用，但最好使用 fakeAsync()/tick() 组合，除非您需要进行 XHR 调用，在这种情况下您必须使用 async()/whenStable() 组合，因为 fakeAsync() 不支持 XHR 调用.

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.

在大多数情况下，它们可以互换使用.除了外部模板和样式未内联编译到组件中以进行测试的组件的情况外，我想不出任何一个必需的组件(即使用 SystemJS).使用 SystemJS 时，会对外部模板和样式进行 XHR 调用.fakeAsync() 不能在进行 XHR 调用时使用.另一方面，在使用 Webpack 时，外部模板和样式会被内联编译，因此您可以使用 fakeAsync().

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().

除此之外，我认为这是风格偏好的问题.我可以说的一件事是假设您需要进行多个异步调用，例如 this example.您需要嵌套的 fixture.whenStable() 调用，当它们变得如此深入时，它们可能会开始看起来很丑陋.

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)
    })
  })
})

如果没有所有那些 fixture.whenStable() 和 看起来 同步的代码，这可能看起来更清晰(并且更容易推理).

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);

我可能要补充的另一件事是我的 OCD 部分 总是需要检查我在 fixture.whenStable() 中的调用是否被调用

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...')
})

假设您忘记将测试包装在 async 中.没有它，测试将在 fixture.whenStable 分辨率之前完成，你永远不会知道它.看起来测试通过了，这是一个误报.实际发生的事情是断言甚至从未被调用过.

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.

出于这个原因，我实际上已经远离 async.但是，如果你喜欢这种风格，并且相信自己总是将测试包装在 async 中，那就坚持下去.但是使用 fakeAsync，一切都是同步调用的，所以断言不可能不被调用.

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.

这篇关于Angular 测试中的 fakeAsync 和 async 有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！