避免测试用户

你的UI代码有两个用户：1）正在与你的组件进行交互的终端用户；2）渲染你的组件的开发者。想象一下，你有以下的UI（取自我的Advanced React Patterns材料）。

注意：这不是一个屏幕截图。你实际上可以与该表单进行交互。为MDX欢呼吧!

这里的表单组件被称为 。这个组件为渲染它的开发者和使用它的用户暴露了某种API。

终端用户：渲染一个用户名字段（因为它不能被改变而被禁用）、标语字段和传记字段。当终端用户改变其中一个值时，重置和提交按钮将被激活。当他们点击重置按钮时，表单就会被重置，而当他们点击提交按钮时，就会保存用户的信息（在我们等待请求完成时显示一个加载状态）。(在这个演示中，如果你在标语或传记中输入 "失败"，那么请求就会失败，你也可以看到错误状态）。

开发者用户：他们在一个 内渲染这个组件，因此该组件可以访问和更新存储在React上下文中的应用程序user 状态和调度。

这是你的组件应该关注的唯一两个用户。这个组件会随着时间的推移经历很多变化。如果它的变化改变了开发者的API或终端用户的期望，那么就需要进行额外的改变。如果它改变了API，（比如也许它接受了一个用户道具，而不是从上下文中访问它），那么开发者用户将不得不改变它的用法以考虑到这一点。如果它改变了用户体验，那么也许需要有解释更新的发布说明，或者更新一些培训材料，例如。

然而，它也可以以其他方式改变。内部重构改变了事情的实现方式（例如，使代码更容易理解），但并不改变开发者使用该组件或最终用户使用该组件的体验。有了这些变化，就不需要在组件之外进行额外的工作。

那么，这与测试有什么关系呢？我经常谈到的一件事是："你的测试越像你的软件的使用方式，他们就越能给你信心。"因此，了解你的软件是如何被使用的真的很有价值。它给了你一个指南，让你知道如何测试这个组件。

但是，我经常看到一些测试是在测试实现的细节（如果你还没有，在继续之前先读一下这个）。当你这样做时，你引入了第三个用户。开发者用户和终端用户对这个组件来说是最重要的。只要它为这两个人服务，那么它就有理由存在。当你维护这个组件的时候，你需要记住这两个用户，以确保如果你破坏了与他们的契约，你会做一些事情来处理这种变化。

但是，一旦你开始测试那些你的开发者用户和终端用户不知道或不关心的东西（实现细节），你就增加了第三个测试用户，你现在必须把这第三个用户记在脑子里，并确保你对影响测试用户的变化也要考虑。

那是为了什么？为了获得 "信心"？但是，当你以这种方式测试事物时，你在获得什么信心呢？你得到的是对测试用户工作的信心。但是没有人关心测试用户。测试用户并不像终端用户那样支付账单。它不像开发者用户那样影响系统的其他部分。

编写包括实现细节的测试是只有坏处而没有好处的。专注于开发者用户和终端用户，你的测试实际上会给你信心，事情将继续为他们工作。当你的测试出现问题时，它就会成为一个提示，让你知道你在其他地方还有其他的改动，以说明你所做的改动。避免测试实施细节，你会好得多。