简单的测试使一切变得简单
简单是一个有着悠久而肮脏历史的词。 多年来，这种含义已被淡化，以至于今天简单被用作一种通用的无礼称赞。 让我们快速浏览一些简单的常用含义，并了解它们如何应用于软件测试 。
简单
这是简单的较常用定义之一，也可能是最危险的定义之一。 Rich Hickey （Clojure的人生仁慈独裁者）对“ 简单”与“简单”作了完整的论述，但总而言之：“简单是主观的，简单是客观的”。 这项措施取决于个人能力和经验，而不是普遍可衡量的任何事物。 任务的难易程度与完成任务所需的努力和痛苦成反比。
当应用于测试领域时，这种思维定势会导致快照测试和类似方法。 尽管这些当然很容易设置和编写，但我个人认为它们的价值不高。 他们记录和盲目信任现有的软件实现，而不是指定的软件的行为应该是什么。
最小的
这个定义困扰着所评估软件的大小和/或数量。 尽管这些措施可以简化，但还有其他更直接的方法可以进行此评估。 这是具有可用于比较方法的客观度量的第一个含义，这是肯定的。
在测试领域，这将引导我们迈向使用像Node.js已经提供的单个assert类型函数的道路。 如果发生故障，用户将负责运行测试并提供消息以进行故障排除。 诸如监视模式或代码覆盖率之类的其他功能肯定会被完全忽略。 测试工具库已广泛期望这种工具。 最终，用户最终将创建自己的即席测试运行器代码，最好将其编写为专用库的一部分。
解开
来自中古英语的简单，源自古法语和法语的简单，源自拉丁语的单纯形（“ simple”，字面意思是“ onefold”），来自sim-（“相同”）+ plicare（“ to fold”）。
Rich Hickey坚信简单的用法，并在我之前链接的演讲中详细介绍了它。 为了理解我们的意思，我们从几条直线的图表开始：
假设这些行是软件依赖项或执行线程。 很明显，这些没有缠结，因此很简单。
现在，如果我们增加行数，但没有一条重叠，这仍然很简单：
仍然可以考虑任何一条独立于其他任何一条线。
但是，如果将相同数量的线缠结在一起，那么我们就会引入复杂性：
减少行数不会再次使这个变得简单：
如果不考虑两者之间的相互影响，仍然不可能孤立地推断第二或第三行。 避免缠结是软件的绝佳目标。 这是简化的必要先决条件，但还不够。 为了填补缺失的空白，我们必须研究简单的原始定义，而不仅仅是其词源。
comp杂
对于simple的最终用法，我们需要查看技术词典的定义 ：
- （ 化学 ）由一种单一物质组成； 没用的 。
- （ 数学 ）一组：没有正常的子组。
- （ 植物学 ） 不 复合 ，但可能裂开。
- （ 动物学 ）由一个人或一个动物群组成； 不复合 。
这些定义的共同主题很明确。 如果可以将某些东西分解成独立有用的部分，则可以通过此含义使其变得更简单。 将项目分解为易于理解/理解的项目管理中的许多最佳实践具有相关的动机。 该概念类似于术语原子，因为它与计算机科学有关。 Stuart Halloway （另一位主要的Clojure贡献者） 就简单性发表了自己的演讲，非常全面地介绍了简单性的定义和其他定义。
尽管无复合是相对客观的（类似于无理），但重要的是确定适当的水平以评估简单性。 通常应用于软件（尤其是代码）的方法的实用性存在实际限制。 编译器和相关工具的过于 简单的水平的介绍一下项目的复杂性，但要避免思维如装配，机器代码，甚至处理器背后的基本物理。
要实现此目标，需要重新考虑应使用哪些基本元素来构建软件。 世界上的Lisps很早就通过将代码表示为数据来解决这一问题。 很难想到一个比清单还难分明的结构，该结构以图灵完整的方式表示代码。 这使针从命令式代码移到了声明式代码。 如果我们可以为测试做类似的事情怎么办？
在我的下一篇文章中，可以解决这个悬念。
随时给我留下评论或将您的投诉发送至@okwolf ！
????
From: https://hackernoon.com/test-code-not-sanity-1e4c0ee51d06