看待单元测试的方式有很多种，但我最喜欢的一种方式是将其视为在没有REPL的语言中拥有REPL的一种尝试。
当您有一个REPL时，您可以调用一个函数并交互地了解它是如何工作的。您可以立即获得反馈-您可以与其进行对话。在动态类型的语言中，这很容易。他们中的大多数都有REPL。在静态类型的语言中，这要困难得多。编译器需要执行其检查。在最坏的情况下，它必须检查一组可传递的依赖项。工具制造商通常甚至不会考虑为这样的语言编写REPL。您将能够与您的代码进行的对话不会立即进行-会有太多的停顿。
尽管有相似之处，但REPL和一系列测试之间有一个关键的区别。测试是封装的、可独立执行的历史片段-与您正在测试的事物精确交互的历史记录。
我们可以尝试通过将REPL对话复制并粘贴到测试文件中来创建测试，但这既笨拙又乏味。谢天谢地，我们是程序员。我们知道该怎么做-自动化。
我用Ruby写了一些概念证明。它被称为C11R(字符的代名词)。
我们的想法是要有一个小工具来帮助我们交互地为现有代码编写单元级表征测试。该工具是对话型的。我们编写代码行来设置我们的环境，使用特定参数运行函数并查看结果。如果我们对结果满意，我们会发出一个命令来保存我们作为测试所做的工作。
如果我们喜欢2作为答案(我们应该这样做)，我们可以使用PUSH命令，然后c11r输出一个测试，以测试我们所学到的内容。
测试Ruby似乎在我们想要的时候给了我们2"；assert_eq(2，1+1)End(#34；Assert_eq(2，1+1)End
>；修复新的>；修复添加a=A。新>；修复添加b=B。新的>；问一个。用(3)+b运行_。使用(2)运行(_)。
在这里，我们使用FIX NEW创建一个灯具(一次只能激活一个灯具)。Fix add命令将行附加到空的fixture，Ask执行上面看到的完全相同的操作，生成答案12。
有关fixture的好处是，它们会一直存在，直到我们再次运行fix new。
>；修复新的>；修复添加a=A。新>；修复添加b=B。新的>；问一个。用(3)+b运行_。Run_with(2)-12>；将跑步者推开一个产量简单的值>；询问a。用(3)+b运行_。Run_with(5)-24；将跑步者推下一次以上的水平跳跃。
如果我们不清楚该装置包含什么，我们可以运行fix来查看它。
很容易把它想象成一个IDE插件来做这种事情，用文本框来保存灯具和问句。我真的很惊讶竟然没有人这么做。这只是一个额外的小东西，可以使特性测试变得更容易。
您可以在这里找到概念证明代码。如果您对它进行进一步的扩展，请与其联系。