匹配数据匹配条件_将匹配器用于前提条件和后置条件

匹配数据匹配条件

对不起，来晚了。 借口，借口。

我觉得我一生中曾经在其他地方看到过这个东西，但是这个想法似乎并没有传播太多。 通常，这可能是由于缺乏对前置条件和后置条件的吸引力。 因此，我们将从这些开始。

前提条件和后置条件

前提条件和后置条件有些过时，已被TDD的泛滥所取代，但我认为不应完全排除它们。

前提条件是您的函数对传递给它的参数的一组假设。

当您接受“原始”类型时，此功能特别有用，但是实际需要的限制要远大于这些类型提供的限制。 例如，您正在接受一个字符串，该字符串应作为文件的路径。 许多人认为您应该将其限制为某种FilePath类型，以确保在创建对象时路径字符串的格式正确。 我认为这是理想的，但并不总是实用的解决方案。 上面这些例子的另一个例子是使用FilePath ，但是前提是所指向的文件已经存在并且具有正确的文件扩展名。 创建专业类型以确保满足这些前提条件几乎绝对是一件痛苦的事情。

后置条件与先决条件相似，但是向调用者的承诺，即已执行某个命令或返回值将具有某种形状或格式（假设已满足先决条件）。

如果实际上已经在代码中对它们进行了测试（当我第一次听说它们时，这只是您放入函数文档中的内容），通常都使用assert s完成。

断言是采用布尔表达式和可选（通常）字符串消息的语句。 如果布尔表达式的计算结果为false，则该语句将使用您提供的消息引发/引发特殊异常。 它们也具有超能力：它们可以消失。 在编译或运行时阶段，用户可以关闭代码中的断言。 其背后的想法是测试运行断言的代码，以便可以及早发现潜在问题。 但是，一旦对代码进行了足够的测试，就可以合理地确定其安全性并关闭生产断言，而不会浪费宝贵的cpu周期（不过，您仍然需要用户输入保护，因此请不要对它们使用断言） 。

使用匹配器

这就是匹配器出现的地方。所谓匹配器，是指任何使用流利的api进行断言的测试库。 关于使用它们的最好的部分？ 几乎肯定已经设置好了它们来声明。 至少，他们抛出了断言异常（这还不够；稍后会更多）。

无论如何，函数中大多数前置条件和后置条件的最大问题是它们很丑陋且占用大量空间。 因此，使用一个可让您表达和测试有关对象的想法的库在解决该问题方面非常有用。

因此，请选择您最喜欢的断言库（我制作的是不匹配的断言库；我非常不完整的youtube视频系列是关于将其转换为kotlin的内容），并深入研究其背后的代码以查看其是否使用assert语句。 如果没有，您可能只需编写一个小辅助函数即可通过assert语句使用匹配器。 并且 ，如果您的语言允许内联函数（如Kotlin那样），则您甚至可以内联该函数调用，以免在断言关闭时浪费调用。

奥托罗

我将给出一个简单的示例，说明其中的一些改进会是什么样子，但是这篇文章已经晚了，再加上任何使用匹配器的人都已经看到了它们比常规断言的好处，所以我觉得这很容易卖出。

最困难的部分可能是说服人们使用前提条件和后置条件，这是一个完全不同的主题。 简而言之，如果您想使用它们，但是觉得它们可能是浪费，那么我建议您在用户交互的大约一层中使用它们，以确保您的用户交互层运行良好。

直到下一次…

翻译自: https://www.javacodegeeks.com/2018/01/use-matchers-preconditions-postconditions.html

匹配数据匹配条件