Vue单元测试：如何使用道具，Vuex商店，观察者，吸气剂等测试复杂的组件

Question

我在vue应用程序中有一个关于单元测试（Jest）的问题-我想这是一个体系结构问题，但是也许特定的代码示例也可以帮助我。

我已经从我的应用程序中绘制了一个或多或少复杂的Vue组件设置。它们仍然简化了，但我想它们应该有助于描述情况。

(PDF Attachment for those preferring non-pixel data :)

我有一个包装器，其中包含三个子组件：

• 搜索（要在地图上搜索的输入字段）
• 列表（商店列表，在地图上也以标记表示）
• 地图（Google地图本身）

我真的很想为此编写一些单元测试，但是设置这些测试似乎非常繁琐，因此我怀疑这是这样做的方法。

它从我加载google maps API的方式开始：包装器异步加载它，设置API密钥等。加载google map API后，它立即将其传递给子级。

当然，只有出现google时，地图才真正真正开始加载，创建和显示标记，例如，我可以使用new this.google.maps.Map()。

即使我想测试 Map 组件的某些方法，我也必须提供一个实际的google对象，因为否则，mount()中的整个初始化过程都会失败。它无法制作地图。

那么我是否必须在测试中加载实际的Google Map API？还是我可以以某种方式跳过安装地图，但仍然测试一些隔离的方法？

此外，您还可以看到我的地图在vuex商店中观察吸气剂：每当 Search 设置的searchCoordinates在我的vuex商店中发生变化时，我都希望来执行一些功能（例如，将地图中心放在新的搜索坐标上，或者如果搜索未返回有效的searchCoordinates，则删除当前的位置标记）。

我如何才能以某种方式打破这些组件之间的链接，但仍然编写良好且有用的测试，从而帮助我确保应用程序执行了应做的事情？

我知道我可以在测试（Medium article about vuex testing）中使用vuex存储。 但是，我仍然觉得整个应用程序之间的联系是如此紧密，以至于无法进行实际的单元测试（一次测试一小块）。 似乎我不仅必须单独安装 Map ，而且还要安装其他组件和带有实际数据的vuex存储，才能真正编写防弹测试。

我在其他例子中苦苦挣扎：

• 在我的mounted()中，我使用this.$store.subscribeAction((action) => {...订阅了一个操作-当然，$ store在我的测试中未定义。 Should I mock it？
• 正如我所说，我正在观看吸气剂：这会引发类似TypeError: Cannot use 'in' operator to search for 'searchCoordinates' in undefined的错误。我还要嘲笑所有吸气剂吗？如果是这样：还有什么要测试？如果我嘲笑（〜=离开）所有vuex东西，在我看来，测试变得毫无用处...

但也许我在这里弄错了。而且我对单元测试还很陌生，因此任何提示都非常欢迎。 提前非常感谢您。我希望有人能提供一些宝贵的意见。 所有这些示例（即使在诸如Vue.js - up and running之类的书中也总是被分解为非常简单易懂的示例，但另一方面却并没有真正反映现实生活中的应用...

欢呼

-----编辑：

我得到某人的needs more focus投票。 因此，我尝试总结一些简单的小问题：

问题摘要

1. 有人对如何测试更大，更复杂的vue应用程序有一般性的意见吗？
2. 是否可以使用google map（或严重依赖于任何第三方代码的组件）测试组件
3. 在这种情况下，嘲笑的吸气剂，储存剂和动作是一个好主意吗？ （我对此表示怀疑）。
4. 为了测试vuex存储中的监视属性，我读了in this thread，认为mapState应该被模拟。 （就我而言，可能是我的吸气剂）。在我看来，嘲笑那些吸气剂是否有意义？
5. 最佳做法是在经过测试的组件中简化尽可能多的事情（例如，我开始重写一些方法，但这些方法（包括google map初始化的方法）无法使我的测试开始并运行：

const initMapMock = jest.fn();
const initMarkersMock = jest.fn();
...
const wrapper = shallowMount(Map, {
    methods: {
        initMap: initMapMock, // replace initMap(), which needs google map API
        initMarkers: initMarkersMock,
      },
    ...

这有意义吗？

Answer 1

深入研究这个问题后，我意识到了一件事： 如果遇到如上所述的复杂情况，那么单元测试可能不是正确的工具！

在这种情况下，end to end testing也称为integration testing会更适合这份工作。

因为我实际上要测试的是，所有不同的组件都以正确的方式做出反应，如果某些内容被更改/触发等等，我需要查看整个图片。

如果回到示例，我希望看到如果搜索输入记录了更改等，地图也会更改。

我最终通过使用无头浏览器googles puppeteer，打开网页，填写搜索查询，然后在DOM中搜索可靠的地图更改来集成一些测试。

不幸的是，由于预算限制，我没有时间真正地详细测试该测试，但是我对应该如何进行测试有了一个想法。

我最初关于模拟商店等的想法将需要大量的工作，而除了围绕单元测试构建类似于应用程序其余部分的大型模拟之外，别无其他，因此这样做是非常愚蠢的。通过集成测试，我可以在测试过程中使用这个已构建的应用程序，但是我的优势是能够同步测试所有内容！

我个人还认为集成测试比单元测试要强大得多，因为它们可以阐明应用程序中开发人员不太容易掌握的部分，并且如果更改了应用程序的某个部分并且其他无法正常工作。

如果有人要添加更多内容，我仍然很高兴听到对此事的意见。

欢呼