安装/拆卸是否会损害测试的可维护性？

Question

这似乎在https://stackoverflow.com/questions/1076263/teaching-testing-habits-to-other-developers/1076288#1076288上引发了一些对话，我认为有必要讨论一下它自己的问题。

干原理似乎是我们对抗维护问题的武器，但是测试代码的维护又如何呢？同样的经验法则适用吗？

开发人员测试社区中的一些强有力的声音认为，设置和拆卸是有害的，应该避免.举几个例子：

• 詹姆斯·纽基尔克
• 杰伊·菲尔德，[2]

事实上，xUnit.net完全出于这个原因将它们从框架中删除(尽管存在克服这种自我限制的方法)。

你有什么经验？安装/拆卸是否会损害或帮助测试可维护性？

UPDATE：执行更细粒度的构造，如JUnit4或TestNG中可用的构造(@BeforeClass、@BeforeGroups等)改变一下吗？

Answer 1

大多数(如果不是全部)有效的用于安装和拆卸方法都可以编写成工厂方法，这样可以避免陷入似乎受到安装/拆卸范式困扰的问题。

如果您正在实现拆卸，这通常意味着您不是在进行单元测试，而是在进行集成测试。许多人将此作为不进行拆卸的理由，但IMO应该同时进行集成和单元测试。我个人会将它们分离成单独的程序集，但我认为一个好的测试框架应该能够支持这两种类型的测试。并不是所有好的测试都是单元测试。

但是，通过设置，在实际运行测试之前，您需要做的事情似乎有很多原因。例如，构造对象状态来为测试做准备(例如，建立依赖注入框架)。这是一个合理的设置理由，但也可以很容易地通过工厂来完成。

此外，类和方法级别的设置/删除也有区别。在考虑你想要做的事情时，需要记住这一点。

我在使用安装/拆卸模式时遇到的最大问题是，我的测试并不总是遵循相同的模式。这让我转而使用工厂模式，它允许我在阅读的同时保持干爽，而且不会让其他开发人员感到困惑。沿着工厂的路线，我已经吃了我的蛋糕了。

Answer 2

它们确实帮助了我们的测试可维护性。我们的“单元”测试实际上是完整的端到端集成测试，它们写入DB并检查结果。不是我的错，当我到这里的时候，他们是那样的，我正在努力改变一切。

不管怎么说，如果一个测试失败了，它将继续到下一个测试，试图从DB中的第一个测试中输入同一个用户，这违反了唯一性约束，而失败只是从那里层出不穷。将用户创建/删除移动到夹具方法中，我们可以看到一个测试失败了，而没有一切都变得混乱，使我的生活变得更容易，也更不稳定。

Answer 3

我认为枯燥原则适用于测试和代码一样多，但是它的应用程序是不同的。在代码中，您需要付出更大的努力才能在代码的两个不同部分不做相同的事情。在测试中，这样做的必要性(做了很多相同的设置)当然是一个难闻的问题，但解决方案不一定是将复制因素分解到安装方法中。它可能会使在类本身中设置状态或隔离被测试代码变得更容易，因此它不那么依赖于这个数量的状态才有意义。

考虑到每个测试只测试一件事情的总体目标，在某些情况下(例如创建一个特定类型的对象)，不可能避免一次又一次地重复做很多相同的事情。如果您发现您有很多这样的测试方法，那么可能值得重新考虑测试方法，例如引入参数化测试等等。

我认为设置和拆卸应该主要是为了建立环境(例如注入使环境成为测试环境，而不是生产环境)，而不应该包含测试的一部分步骤。