这个争论早已结束。你应该测试你的关键任务的代码。
每个人都接受，现在测试代码比等待用户以后抱怨要好。
每个人都同意，测试应该是自动化的。
几乎每个人都有过这样的经历：测试将他们从生产错误中拯救出来......或者如果测试到位的话，他们就会被拯救出来。
我在twitter上问大家在测试方面有什么困难。当你试图确定要测试什么，你有多少时间来测试，测试的粒度，什么是模拟的，什么是保持真实的，或者只是建立良好的测试工具和测试环境的艰巨任务时，就会出现挣扎。或者，当你发现自己在两个地方写同样的代码时，挫折感就会悄然而至。🤪
测试的另一个很大的挫折来源--如果你以前听过这句话，请阻止我们--是当你每次接触测试的代码时，基本上都要重写你的测试。一旦你把头从键盘上抬起来，你就得问自己。"好吧......那么我们为什么又要测试？这只是给运载代码增加摩擦"。当你重构一个组件时，你的测试就会中断，这是非常令人沮丧的。😡我也不想写测试。
几年前，当我开始做测试时，我很挣扎。我挣扎得很厉害。我花了无数的时间来学习、建立和重建工具。我甚至做了整整一个小时的演讲，名为"ES6、Webpack、Karma和代码覆盖"。 花了整整60分钟来解释如何让这些工具很好地一起工作。在幕后又花了几十个小时来解决我在演讲中所解释的问题。
但我致力于找出并帮助建立做这件事的最佳方法。我需要它，我知道我的开发者伙伴们也需要它。
挣扎和挫折不一定是你的经历。你不需要花几十个小时来弄清楚如何在你的代码库中设置测试。**我已经为你做了这些。**而且工具已经改进，我可以告诉你如何使用它们。我可以教你一些技巧，这些技巧可以减轻你的痛苦和挣扎，让你从你的测试库中获得你所寻找的信心。
这里有一个提示，供你在下次测试代码时使用，它将帮助你回答 "我应该测试什么 "的问题。按照这个过程：
- 你的未测试的代码库中的哪一部分如果坏了就会非常糟糕？ (检查过程)
- 试着把范围缩小到一个或几个单元的代码（当点击 "结账 "按钮时，一个包含购物车物品的请求被发送到/checkout）。
- 看看这段代码，并考虑谁是 "用户"（开发人员渲染结账表单，最终用户点击按钮）。
- 写下一份指示清单，让该用户手动测试该代码，以确保它没有被破坏。(用购物车中的一些假数据渲染表单，点击结账按钮，确保用正确的数据调用模拟的/结账API，用一个假的成功响应来回应，确保显示成功信息）。
- 把这个指令列表变成一个自动测试。
有了我要告诉你的工具和技术，这个过程将成为一种自然的习惯。💯
停止挣扎跟着我。
