这似乎在 another question 上引发了一些讨论。和我
认为值得转入自己的问题。
DRY 原则似乎是我们对抗维护的首选武器
问题，但是的维护呢？测试码 ?做同样的经验法则
申请？
开发人员测试社区中的一些强烈声音认为
安装和拆卸是有害的，应该避免......仅举几例:
事实上，xUnit.net 正是出于这个原因，将它们从框架中完全删除了
(虽然有 ways to get around this self-imposed limitation )。
你有什么经验吗？设置/拆卸是否会伤害或帮助测试可维护性？
更新 :像 JUnit4 或 TestNG(@BeforeClass、@BeforeGroups 等)中可用的更细粒度的结构会有所作为吗？
最佳答案
的大多数(如果不是全部)有效 setup 和 teardown 方法的用途可以写成工厂方法，允许 DRY 而不会遇到似乎受到 setup/teardown 范式困扰的问题。
如果您正在实现拆解，通常这意味着您不是在进行单元测试，而是在进行集成测试。很多人以此为理由不进行拆解，但 IMO 应该同时进行集成和单元测试。我个人会将它们分成单独的程序集，但我认为一个好的测试框架应该能够支持这两种类型的测试。并非所有好的测试都是单元测试。
但是，通过设置，您需要在实际运行测试之前执行操作似乎有很多原因。例如，构建对象状态以准备测试(例如设置依赖注入(inject)框架)。这是设置的正当理由，但可以通过工厂轻松完成。
此外，类和方法级别的设置/拆卸之间存在区别。在考虑您要做什么时，需要牢记这一点。
我在使用 setup/teardown 范例时遇到的最大问题是我的测试并不总是遵循相同的模式。这使我转而使用工厂模式，这使我可以在具有 DRY 的同时具有可读性，并且不会让其他开发人员感到困惑。走工厂路线，我已经可以吃蛋糕了。
关于unit-testing - 设置/拆卸会损害测试的可维护性吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1087317/