单元测试中重复的代码是否更容忍？ [英] Is duplicated code more tolerable in unit tests?

问题描述

前段时间，我破坏了几个单元测试，并对它们进行了重构以使其更加完善。 DRY -每次测试的目的不再明确。在测试的可读性和可维护性之间似乎需要权衡取舍。如果我将重复的代码留在单元测试中，则它们更具可读性，但是如果我更改 SUT ，我将不得不查找并更改重复代码的每个副本。

I ruined several unit tests some time ago when I went through and refactored them to make them more DRY--the intent of each test was no longer clear. It seems there is a trade-off between tests' readability and maintainability. If I leave duplicated code in unit tests, they're more readable, but then if I change the SUT, I'll have to track down and change each copy of the duplicated code.

您是否同意这种折衷方案存在？如果是这样，您是希望测试是可读性还是可维护性？

Do you agree that this trade-off exists? If so, do you prefer your tests to be readable, or maintainable?

推荐答案

重复的代码只是单元测试代码中的一种味道和其他代码一样多。如果测试中有重复的代码，则由于要更新的​​测试数量不成比例，因此很难重构实现代码。测试应该可以帮助您信心十足地进行重构，而不是使您无法负担要测试的代码的沉重负担。

Duplicated code is a smell in unit test code just as much as in other code. If you have duplicated code in tests, it makes it harder to refactor the implementation code because you have a disproportionate number of tests to update. Tests should help you refactor with confidence, rather than be a large burden that impedes your work on the code being tested.

如果复制是在夹具中进行的，请考虑进行 setUp 方法的更多使用或提供更多（或更灵活）的创建方法。

If the duplication is in fixture set up, consider making more use of the setUp method or providing more (or more flexible) Creation Methods.

如果重复代码在操纵SUT的代码中，请问自己为什么要进行多个所谓的单元测试完全相同的功能。

If the duplication is in the code manipulating the SUT, then ask yourself why multiple so-called "unit" tests are exercising the exact same functionality.

如果重复项位于断言中，则可能需要一些自定义声明。例如，如果多个测试具有一串断言，例如：

If the duplication is in the assertions, then perhaps you need some Custom Assertions. For example, if multiple tests have a string of assertions like:

assertEqual('Joe', person.getFirstName())
assertEqual('Bloggs', person.getLastName())
assertEqual(23, person.getAge())

然后您可能需要一个 assertPersonEqual 方法，以便可以编写 assertPersonEqual（Person（'Joe'，' Bloggs'，23），个人）。 （或者也许您只需要在 Person 上重载相等运算符。）

Then perhaps you need a single assertPersonEqual method, so that you can write assertPersonEqual(Person('Joe', 'Bloggs', 23), person). (Or perhaps you simply need to overload the equality operator on Person.)

正如您提到的，这很重要使测试代码可读。特别重要的是，明确测试的意图。我发现，如果许多测试看起来大致相同（例如，四分之三的线相同或几乎相同），则很难在不仔细阅读和比较的情况下发现并识别出明显的差异。因此，我发现进行重构以消除重复有助于的可读性，因为每种测试方法的每一行都与测试目的直接相关。比起直接相关的行和只是样板的行的随机组合，对读者而言，这要有用得多。

As you mention, it is important for test code to be readable. In particular, it is important that the intent of a test is clear. I find that if many tests look mostly the same, (e.g. three-quarters of the lines the same or virtually the same) it is hard to spot and recognise the significant differences without carefully reading and comparing them. So I find that refactoring to remove duplication helps readability, because every line of every test method is directly relevant to the purpose of the test. That's much more helpful for the reader than a random combination of lines that are directly relevant, and lines that are just boilerplate.

也就是说，有时测试会遇到复杂的情况，相似，但仍然有很大不同，因此很难找到减少重复的好方法。使用常识：如果您认为测试是可读的并且明确了它们的意图，并且在重构测试调用的代码时可能会需要更新理论上最少的测试数量，那么您会感到自在，然后接受缺陷并转移从事更具生产力的工作。当灵感来袭时，您总是可以稍后再重构测试！

That said, sometimes tests are exercising complex situations that are similiar but still significantly different, and it is hard to find a good way to reduce the duplication. Use common sense: if you feel the tests are readable and make their intent clear, and you're comfortable with perhaps needing to update more than a theoretically minimal number of tests when refactoring the code invoked by the tests, then accept the imperfection and move on to something more productive. You can always come back and refactor the tests later, when inspiration strikes!

这篇关于单元测试中重复的代码是否更容忍？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！