junit断言模糊匹配_自定义断言匹配器的缺点

junit断言模糊匹配

十年前，我们知道的唯一测试是用户接受测试。 过去十年见证了一个巨大的飞跃：它带来了单元测试。 单元测试在JUnit中变得很流行。 反过来， TestNG在测试类中添加了注释，从而使注释变得更加容易。 然后， EasyMock提供了在测试上下文中模拟类依赖关系的方法，而Mockito简化了这样做的过程。 有人认为单元测试已经说完了，我们应该朝着更有价值的目标迈进。

我认为事实与事实没有什么不同。 我确实认为下一步将使测试更易于维护。 在我的职业生涯中，我必须维护没有单元测试的软件，这很糟糕。 但是，当我不得不使用带有测试的软件进行工作时，我很难理解，我不能肯定地说它是否更好。 花时间确保没有回归和副作用是一回事，花时间调试测试复杂性是另一回事，管理层对此几乎没有期望。 断言语句是一个特别的障碍。 我了解起初似乎很奇怪。 以下说法在世界上怎么会变得难以理解？

Assert.assertFalse(myList.isEmpty());

好吧，我推断有些人一定有足够的经验来编写相同的断言，并提供了一些通用的API来对其进行测试。 FEST和Hamcrest就是此类测试商品的示例，它们使我们可以通过使用在声明域的DSL来提高生产力。 顺便说一句，我完全同意他们的用法，甚至在我的团队中推广它。 但是，Hamcrest还提供了一个用于创建我们自己的自定义匹配器的API：乍一看，创建这样的匹配器确实是有帮助的，但我会尝试提出一些建议。

首先，可维护性如何？ 如果更新后测试失败，是因为我的代码，匹配器还是两者的结合？ 我将不得不询问原始编码器，但是在大多数情况下，我会自己决定这些事情。 这可能会涉及出汗，辛劳和大量调试。 单独计算，成本不高，但与匹配器的数量成指数比例。

然后，为了降低匹配器中的错误的可能性，必须自己对其进行测试！ 他们各自的测试是否需要断言匹配器？ 看来这将是海龟跌入谷底。 同样，成本必然会上升。

而且，在学校里我们被告知代码重复是不好的（许多工具提供了这个指标），应该不惜一切代价避免这样做。 我只能支持第一个公理，就像我必须谴责第二个公理一样，尤其是“不惜一切代价”这一部分。 这不是真的！ 复制是重用的第一层，我希望前面的论点对编写和维护自定义匹配器的成本提出我的观点。 例如，如果我们重复两行三遍，那在我眼中还不足以证明匹配器的增加成本是合理的！

最后，这似乎很奇怪，但是测试不是软件的目标 ，仅仅是达到目的的手段（我将在下一篇文章中写一些东西）。 我们的任务既不是使CV更加明亮 ，也不是为了承担最高的代码覆盖率挑战。 我们只是在向客户交付软件的同时获得报酬，同时尊重成本，延迟和质量的三位一体。 如果编写自定义匹配器可以帮助我们实现此目标，那么很好，但是这种情况是否有效取决于上下文。

目前，在以下情况下编写自定义匹配器对我来说似乎是有利的：

• 这样做有真正的优势。 搜索存在多少条重复行，以及在匹配器中将它们分解为成本有效的方法。
• 这不会影响投放。 如果我们正在编写有史以来最好的匹配器，并且已下令交付产品，该怎么办？ 客户不在乎匹配器。
• Matchers永远不应该由单个开发人员拥有，而应该由整个团队拥有。 这样可以避免或至少降低必须调试匹配器以了解其目标的风险。

总之，我希望本文能使您考虑整个自定义匹配器的内容。 下次您要创建匹配器时，请考虑一下：这可能是一件好事，但不一定如此。

翻译自: https://blog.frankel.ch/cons-of-custom-assertion-matchers/

junit断言模糊匹配