如果你不写单元测试……这是一个技能问题

今天我看到了这条推文：

内容如下

有没有人写过文章或资料，介绍他们用过什么策略来向同事介绍测试这门奇妙的艺术？以防他们说“我不同意测试”。

这部分：

“我不同意测试。”

哦天哪，这跟积极姿态无关。考虑到我们如今拥有的生成工具，恐怕……

这是技能问题

我去过那里。

• 您知道这个理论：测试对代码库有好处。
• 它们充当开发人员的文档。
• 他们提供保险。
• 它们让人安心。

但真正的问题在于，问题不在于“立场”，而在于你不知道如何编写测试。

您已经尝试过官方文档，它看起来像这样：

function foo() { return 42; }

expect(foo()).toBe(42)

您已经知道如何测试简单的“输入输出”功能。

但在现实世界中，事情更加复杂……

• 您想测试一个 React 组件，但它依赖于 4 个上下文、页面位置和一个路由器？
• 您想测试一个 Node.js 对象，但它依赖于 8 个外部库，内部状态混乱，并且需要从德古拉城堡进行一些模糊的预取？
• 您想测试一个 Python 类，但它与 RabbitMQ 绑定，并且让系统准备就绪是一场噩梦？

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

没关系

测试是一门技能，它不同于常规的编码。

从小处着手，打破依赖关系，并隔离您可以控制的部分。

控制是关键：

当您能够测试您的“组件”时，您就完全控制了您的代码。

*“组件”作为一个抽象术语，你的类，你的模块，你的系统......

你知道我什么时候终于理解了——理解（真的理解）React 上下文？当我能够测试它们的时候！

测试 React Context Provider

曼努埃尔·阿特罗·安吉塔 🟨 ・ Feb 20 '22

#react #javascript #测试 #教程

另一篇相关文章：

测试 React 自定义 Hook

曼努埃尔·阿特罗·安吉塔 🟨 ・ 2023 年 2 月 13 日

#webdev #javascript #react #typescript

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

记住，这是一项技能。而且像任何技能一样，它是可以学习的。

这是一个过程。