hamcrest

我在Hamcrest库上做了几篇文章 ，我确实很喜欢使用它，但是我希望对其进行一些更改。 我了解他们所做的大多数设计决策，但我认为其中一些确实不值得。

介绍Litecrest

我对库所做的大多数更改都有助于减轻Hamcrest的负担，因为我觉得有些事情不必要地减轻了负担。 这就是为什么我将更改称为Litecrest。 它不会是一个实际的库； 这只是大声思考。 我也希望您能从中学到一些有关设计库的知识。

没有说明

Description接口以及StringDescription和BaseDescription类实际上并不值得。 他们提供了列表转换为字符串好看一些不错的方法，但toString()在所有这些方法应该是足够的。 如果不是这样，可以将一些protected final方法放在BaseMatcher ，以方便地为列表构建字符串。 当然，这并没有真正遵循SRP密切，所以你可以使用类似 Description ，以提供方便的方法。

说明，否则不是很有帮助。 它的存在性假设它专门用于提供从长远来看可能不是String的输出。 作为一个使用良好的库，将其从String更改为与输出无关的类型会破坏向后兼容，但这种更改不太可能需要。 应用YAGNI ， Description类就在厕所下面。

无输出参数

所述describeTo()和describeMismatch 不宜服用在Description或附加物体的任何其它类型的字符串，尤其是作为out参数（某物，以避免尽可能经常）。 既然这些方法没有开始的返回类型，那么绝对没有理由使用out参数。

仔细研究问题，您将发现根本没有理由使用参数。 我了解到，他们可能一直在试图迫使匹配器的创建者不使用String串联，但事实并非如此。 如果匹配器的描述只是一个简单的小字符串，则没有理由他们不应该仅仅返回该字符串。 就个人而言，我将删除Description参数，并为它们提供String或CharSequence的返回类型。 我考虑使用CharSequence因为那样会给使用StringBuilder带来更大的动力，但是简单地返回String也不是什么大问题，因为他们可以在其上调用toString() 。 不过，我也可能会使用CharSequence ，因为我将在断言逻辑中使用StringBuilder来将输出放在一起，并且StringBuilder也可以接受CharSequence ，因此唯一的toString()必须在完成输出时被调用。

类型安全

Matcher接口采用通用参数，该参数与matches()方法一起使用，但是所述方法采用Object而不是通用类型。 javadoc声称这是由于类型擦除引起的，但我不认为这是一个问题。 我没有做任何挖掘来尝试是否可以将其切换为通用类型，但是如果我发现您实际上可以使用通用类型，则可以。 这消除了对TypeSafeMatcher的需要，因为它也检查null，因此可以用更简单的NullCheckingMatcher代替，或者仅实现它，以便断言在捕获到NullPointerException将不匹配描述更改为“为null”。 通过执行所有这些操作，我们可以消除所有其他双倍的基类，这些基类必须加倍以覆盖类型安全匹配器和不那么重要的匹配器。 （例如： CustomMatcher和CustomTypeSafeMatcher ， DiagnosingMatcher和TypeSafeDiagnosingMatcher ，以及我加倍的ChainableMatcher ，摆脱了两个DiagnosingMatcher的影响；它们的设计很差，两次调用matches() ）

更改一些名字

我真的不喜欢describeTo()这个名字。 应该是describeExpected()或describeMatch() 。 我了解他们遵循JMock Constraints中SelfDescribing的命名约定，但是看到他们没有费心完成其余方法签名的复制，实际上并没有任何SelfDescribing 。

CustomMatcher S的关系被称为OneOffMatcher S或QuickMatcher秒。 Custom是一个令人误解的名称，听起来您需要对其进行扩展才能创建自己的匹配器。

文档中的更多示例

我不确定该库中有几类有用，因为它们的文档未显示其用法。 Condition就是其中之一。 从少量的文档看来，这似乎是相对有用的，但是由于它没有提供使用示例（并且它是一个具有内部接口和两个内部类的相对复杂的文件），我不知道如何使用它。 它还没有记录其公共方法，因此我不确定它们是否需要大量研究。

FeatureMatcher已有不错的文档，但是同样，没有示例。

那些为图书馆编写文档的人在任何时候都牢记这一点； 如果不是很明显（通常，即使不是很明显），则应给出使用中的类的示例。

删除无关的类

其中一些已经被直接或间接地解决了。 删除Description及其所有子类。 删除SelfDescribing ，因为它仅在Description仍然存在时才真正有用。 删除所有TypeSafe版本的基本匹配器。 卸下Diagnosing匹配器。 我不确定是否应该删除Condition因为我没有太大用。 如果保留Condition ，那么最终在核心org.hamcrest包中有五个原始的十一个类，在api org.hamcrest包中有四个原始的两个接口。

现在，让我们深入研究org.hamcrest.internal包。 ArrayIterator没什么用，因为您只能使用可以与foreach循环一起使用的数组。 NullSafety似乎模仿Arrays.toList()功能，但是用IsNull匹配器替换了null匹配器。 我看不到这有什么帮助，因此将其删除。 ReflectiveTypeFinder可能最终会有用。 我只看到它在TypeSafeMatcher和FeatureMatcher ，尽管我不确定在FeatureMatcher使用了多少。 不过，我会保留。 最后两个处理的是SelfDescribing ，我们已将其删除，因此这两个处理也是一样。 这仅使ReflectiveTypeFinder脱离了以前的五个类。

我不打算讨论所有其他匹配器。 在大多数情况下，已添加它们的用途。 由于删除了这么多的基类，几乎所有的类都可能必须进行更改。

Lambdas！

如果将新的功能范例也应用到hamcrest，则可以扩展匹配器概念的实用性。 我没有想太多，但是对于一次性匹配器，您可以修改库以包括一个新的assertThat()方法，如下所示：

public static  void assertThat(T item, String description, Predicate matcher) {if(!matcher.test(item)) {StringBuilder output = new StringBuilder();output.append("Expected: ").append(description).append("\n      but: was").append(item.toString());throw new AssertionError(output.toString());}
}

这将使您可以编写类似于以下内容的断言：

assertThat("cats", "doesn't contain \"dogs\"", str -> !str.contains("dogs"));

实际上，实际上我已经在ez-testing迷你库中添加了LambdaAssert类，因此您可以将其与原始的hamcrest库一起使用。

匹配器接口

实际上有一个Matcher接口是毫无意义的，因为hamcrest希望您扩展BaseMatcher而不是实现Matcher 。 如果您非常不想让任何人实现，那么为什么要创建一个接口？ 特别是因为BaseMatcher为我们所做的唯一事情就是为describeMismatch()创建一个默认实现describeMismatch()并“实现”放置在此处的不赞成使用的方法，告诉您使用BaseMatcher而不是Matcher ）。

如果您真的不希望人们使用该界面，请摆脱它。 就我个人而言，由于无论如何我总是会重写describeMismatch() ，因此我认为只实现接口就完全可以了，而不必让JVM加载实际上为我提供任何东西的基类。

另外，由于我们现在有了Java 8，所以该接口可以只使用默认方法来实现默认实现。 我知道可以避免这种情况，因为较旧的Java版本将无法利用这一点。

所以，要么只是做BaseMatcher或没事的Matcher正在实施。

奥托罗

我还想更改其他一些小事情，例如，迫使人们重写describeMismatch()而不是提供默认值，但是我甚至不确定那个，因为默认值通常足够有效。 无论如何，即使您有一个受欢迎的图书馆，也并不意味着它是完美的。 始终注意进行重构。

不幸的是，所有这些更改都不是向后兼容的，但有时是值得的。

翻译自: https://www.javacodegeeks.com/2015/01/redesigning-hamcrest.html

hamcrest