Vue-test-utils模拟从另一个组件获取响应

Question

我试图在一些Vue组件上使用vue-test-utils和jest设置单元测试，这些组件从另一个Vue组件(ApiCalls.vue)中检索响应，后者负责使用fetch()调用远程API。使API调用的组件返回此类型的对象：

{
  status: <fetch response status>,
  body: <fetch response body>
}

待测试组件概述(MyComponent.vue)：

import ApiCalls from './ApiCalls.vue';

export default {
  data() {
    return {
      resultsFromAPI: null
    }
  },
  mounted() {
    this.getSomeData();
  },
  methods: {
    async getSomeData() {
      const APIResponse = await ApiCalls.data().getSomeData();
      if (APIResponse.status === 200) {
        this.resultsFromAPI = APIResponse.body;
      }
    }
  }
}

测试规范概述：

import { shallowMount } from '@vue/test-utils';
import MyComponent      from './MyComponent.vue';

const wrapper = shallowMount(MyComponent);

test('check data from API', () => {
  expect(wrapper.vm.resultsFromAPI).toBe(<stuff fromAPI>);
});

我试图像这样模拟函数getSomeData：

wrapper.vm.getSomeData = jest.fn(() =>
  Promise.resolve({
    json: () => Promise.resolve({status: 200, body: { result: 'blabla' }),
  })
);

或

const getSomeData = jest.fn(() =>
  Promise.resolve({
    json: () => Promise.resolve({status: 200, body: { result: 'blabla' }),
  })
);

但是它不起作用，我在vue-test-utils或jest config中找不到任何线索.任何帮助都将不胜感激。

Answer 1

首先，您不应该在Vue构造函数上调用data()函数。我的意思是，你可以只是为了刺激，但你已经知道它会回来，对吧？这不是什么秘密。“魔术”是构造函数在返回的Vue实例上为data()结果的每个成员创建反应性属性，其值不是undefined。

现在，在您的嘲弄尝试中找到真正的问题:您似乎误解了模拟的目的，因此也误解了单元测试的目的。模仿是将外部系统(对您的组件)替换为总是在期望外部系统运行的情况下运行的东西。因为您只应该测试当前的单元(组件)，而不是其他的。您的测试不应该依赖于运行测试的机器是否能够访问API，如果API当前处于关闭状态，等等.

但是从不嘲笑正在测试的组件的内容！

如果这样做，您就会在测试仍然通过时为您的测试组件造成破坏的可能性，因为在测试中，已损坏的方法将被一个坚实的模拟替换。您需要在方法中运行实际代码的测试，该测试在组件失败时失败，并且在组件按预期运行时通过。

您应该测试组件是否为所有可能的输入生成预期的输出。

在您的示例中，您应该使用一些行为方式来模拟ApiCalls，就像您期望ApiCalls的行为一样，基本上有两件事情您应该进行测试：

当当前组件已被挂载(并使用正确的params调用)时，

• ApiCalls.getSomeData只被调用一次(也不多)
• ，当响应状态为200时，组件的.resultsFromAPI将填充返回的数据，否则将保持为null。

您的组件不应该关心ApiCalls是什么。换句话说，ApiCalls应该是可模拟的。它可能是真正称为后端或后端模拟的东西。重要的是组件如何对来自ApiCalls方法返回的不同响应作出反应。

您可以测试的最后一件事是，当ApiCalls不可用时会发生什么，如果您认为这是一种实际的可能性(或者如果它永远不会解决的话会发生什么--它会停止)。这些都是边缘情况，通常不包括在内，除非客户端有特定的请求，否则应用程序应该从结构错误中恢复过来(这是一种罕见的情况)。

总之，不要编写一个在实际组件损坏时可能通过的测试。这是可能让你当场被解雇的事情之一(这是一个隐喻--用你在失败时可能损失的东西来代替:客户、客户、生活、账户、声誉等)，如果有什么重要的事情实际上取决于你的组件是否按照预期运行。因为不仅您编写的测试未能捕获bug，而且实际上它谎称已经测试了组件(它从来没有这样做-它测试组件模拟)。因此，它给人一种虚假而危险的安全感。

使用描述in this answer的方法来模拟ApiCalls的方法。

注:平心而论，我本可以把你的问题标记为上述问题和许多其他问题的重复。以前也有人问过这个问题。

然而，我选择发布这个冗长的警告作为答案(希望您和其他人会发现它有用)，并概述了不嘲笑应该被嘲弄的内容和不进行适当测试的危险，因为我认为UTs的编写方式是一个大问题。

这种类型的错误(以及它们的危险)的部分原因也在于UTs是强制性的，而很少有编码公司将任何精力放在教学测试原则上。