软件测试作为文档工具

为什么测试可以完美地讲述代码的故事

我正在 GitHub 上开展一个大型UI 测试最佳实践项目，我分享这篇文章是为了传播它并获得直接反馈。

编写文档通常很困难，它需要精准细致的工作，并且需要团队所有成员理解并重视编写优秀的文档。编写文档是一项无私的工作，而所谓的无私，是指它奉献给其他开发人员以及我们的未来。

我一直坚信，测试方法论不仅能确保我们编写的代码符合项目需求，确保不会引入回归问题，还能记录代码和用户流程（请记住，编写代码的人是前端开发人员）。最近，我的“测试即文档”理念得到了进一步的印证：我跳槽到一家新公司，几乎没有时间告诉新来的开发人员我之前做了什么。

将项目移交给新的开发商

首先，看一下：

• 我正在开发的后台架构，使用 React 开发，并使用 Cypress 和 Jest 进行测试

Conio后台的架构。

• 一些用户流程的视频

• 一些 Jest 测试的屏幕截图

Conio Backoffice的一些集成测试。请注意，当时我违反了一条黄金测试规则：任何测试都不应共享状态。

说明项目做什么以及如何做的步骤如下：

• 讲述一些关于项目和整个架构的技术细节

• 要求新开发人员探索 Storybook 故事

• 要求新开发人员运行并观看 Cypress 测试

• 要求新开发人员运行并读取 Jest 测试的输出

• 要求新开发人员阅读测试代码

• 衡量新开发人员对项目的理解，要求他改变和测试一些流程

交接过程非常顺利，我决定写这篇文章😊。新来的开发人员（我得承认，他很聪明，你好，Lorenzo👋）让我对用户流程了如指掌，并且能够自信地修改项目的主要部分（以及相关的测试）。尽管如此，他还是能够像我之前测试项目其他部分一样，实现新的用户流程并进行测试。

好的和坏的部分

好吧，即使我对这次体验相当满意，我也必须承认有些地方并不完美。我指的不是流程本身，也不是将测试用作文档工具的想法，而是我编写测试的方式。有些细节误导了应该阅读我测试的开发人员的理解。让我们快速回顾一下我编写的测试的优缺点：

我的测试结果很好：

• 使用 Cypress 从 UI 角度测试所有内容：对于前端流程来说，UI 比一切都更重要

• 拥有一本精心编写的 Storybook：在Storybook 中编写故事本身就是一种测试！这是一种可视化测试，可以使用 Storyshots 之类的插件轻松完成。

• 简洁易懂的测试代码：测试代码必须极其简洁。例如，易于阅读、无条件、抽象程度低、日志记录良好等等。始终记住，测试必须降低阅读和理解代码的认知负担，因此其复杂度应该比需要理解的代码低一个数量级。

• 在代码和测试之间共享一些步骤“id”：如果用户流程很长，在代码和测试代码之间共享一些“步骤”可能会很有用（我的注释是“/** #1 /”，“/ * #2 */”等）

• 对部分代码（例如一些 saga，如上图所示）进行更多低级测试，这些部分代码可能难以理解（因此难以更新或重构为更简单的版本）

我的测试出了什么问题：

• 一些测试描述并不完美：在撰写测试描述时，良好的叙事技巧非常重要

• 不利用Gherkins自己编写测试：我一开始经验不足，所以决定不考虑用 Gherkins 编写 BDD 风格的测试。你可以看看这篇文章，了解 Gherkins 的叙事优势。

• 在不同的测试之间共享一些 Fixture：这些 Fixture 是服务器响应的静态版本，当它们相同时回收它们的想法本身并没有错，但我应该更注意它们的名称。在注册和登录流程中都使用“registration-success.json” Fixture（这只是一个例子，我在更复杂的情况下也犯过这个错误）会给新开发人员留下一些疑惑。这类事情会留在编写代码的开发人员的记忆中（为什么你可以将同一个 Fixture 用于两种不同的情况？），从公司的角度来看，这真的很糟糕。

最后，编写测试可以让你：

• 有描述良好的文档：测试的描述总是从用户的角度编写，而不是从开发人员的角度编写

• 轻松交接

• 避免依赖某些员工（例如你）的历史记忆

• 记录一些在阅读代码时可能听起来“奇怪”或很复杂但从用户角度来看完全合理的选择

更不用说明显的测试优势，比如无回归工作、利用一些自动化和快速工具等。😊

我很想了解你在这方面的经验！欢迎留言分享哦🤗