今天我看到了这条推文：

哪個讀取

有没有人写过文章或类似的内容，讲述他们用来向同事介绍测试这项美妙技能的策略？特别是在那些人表示“我不同意测试”的情况下？

这部分:

"我不同意测试。"

哦，我亲爱的，这并不是关于一个_主动_的姿态。考虑到我们今天拥有的生成工具，我恐怕……

我经历过那个。

• 你了解理论：测试对代码库有好处。
• 它们充当开发者的文档。
• 它们提供覆盖率。
• 它们给开发者带来安心。

但真正的問題在於此。這不是關於「立場」的問題。只是你不知道如何寫測試。

而且你已经参考了官方文档，它们看起来大致如下：

    function foo() { return 42; }

    expect(foo()).toBe(42)

进入全屏模式 退出全屏模式

你已经知道如何测试一个简单的"输入-输出"函数。

但在现实世界中，事情要复杂得多...

• 你想测试一个React组件，但它依赖于4个上下文、页面位置和一个路由器？
• 你想测试一个Node.js对象，但它依赖于8个外部库，内部状态混乱，并且需要从德古拉的城堡中进行一些晦涩的预取？

• 你想测试一个Python类，但它与RabbitMQ绑定，并且准备系统的过程是一场噩梦？

• • *

第一步是承认：这是一个技能问题。

这也没问题

测试是一种技能。它与常规编码不同。

从小开始，拆分依赖项，并隔离你可以控制的部分。

控制是关键：

你可以测试你的 "组件" 的那一刻，就是你完全掌控你的代码的那一刻。

*"组件"作为一个抽象术语，可以指你的类，你的模块，你的系统...

你知道当我真正理解——理解（就是真的理解）React 的上下文（Context）是什么时候吗？当我能够测试它们的时候！

## 测试一个React Context Provider Manuel Artero Anguita 🟨 ・ Feb 20 '22 #react #javascript #testing #教程

另一个相关帖子：

## 测试一个React自定义钩子 Manuel Artero Anguita 🟨 ・ 2023年2月13日 #webdev #javascript #react #typescript

模拟库的存在是有原因的。掌握可用的工具，无论是 Jest、Playwright、Pytest……

记住，这是一项技能。和任何技能一样，它可以被学习。

这是一个过程。