在单元测试中，将预期结果建立在实际结果的基础上是不好的做法吗？

测试用例的设计应考虑到程序的要求。如果只需要验证字符串的一部分，则仅验证字符串的该部分。如果整个字符串需要验证，请验证整个字符串。通过单元测试应强烈表明已遵守所有可直接测试的需求。

如果一个错误有可能在你没有看到的部分中插入了奇怪的东西，你的测试方法将无法捕捉到这些错误。如果这是一个可以接受的风险，那么你可以选择接受这个机会，但你必须认识到这种可能性并决定你自己的容忍度。

您有一个从输入数据生成字符串的函数。可以选择让测试用例始终测试整个生成的字符串，尽管每个测试的测试目标是验证该字符串的非常特定的部分。你认为这种方法不好是正确的：由此产生的测试将过于宽泛，因此很脆弱。对于任何更改，它们都会失败/必须维护，而不仅仅是在更改影响生成字符串的特定部分的情况下。看看 Meszaros 对脆弱测试的讨论，特别是“测试对软件应该如何构建或行为说得太多”的部分，你可能会发现很有启发性： http://xunitpatterns.com/Fragile%20Test.html#Overspecified%20Software

实际上，更好的解决方案是使您的测试更加集中，因为您也希望它们更加集中。但是，您选择的方法有点奇怪：您获取生成的字符串，制作一个副本，使用手动编码的预期字符串部分（在相应测试中处于焦点）修补副本，然后再次比较两个完整的字符串，结果和修补的结果。从技术上讲，您已经创建了一个测试，该测试真正只关注预期的部分，因为围绕该部分的字符串的其他部分将始终相等。然而，这种方法令人困惑：对于不完全理解测试代码的人来说，你似乎好像是根据代码本身的结果来测试代码的。

你为什么不反过来做：取结果字符串，剪掉感兴趣的部分，并将这部分与硬编码的期望进行比较？在您的示例中，测试将如下所示：

test_date_part_of_generated_string:
   date = 1990-01-01
   actual_full_string = generate_string(name, date)
   actual_string_parts = actual_full_string.split(' ')
   actual_date_part = actual_string_parts[-7]
   assertEquals('1990-01-01', actual_date_part)

在某个时间点，我同意审查代码的人的观点：让测试变得残酷简单。同时，我想测试代码的每个低级部分，以获得完整的测试覆盖率，并进行TDD。

正如你所指出的，问题在于残酷的简单测试是重复的，当你需要为新场景改变东西时，你必须改变大量的测试代码。

然后我和一个比我有二十年经验的人一起编码，我知道他是一个世界级的程序员。他说：“你的测试太重复了，重构它们，使它们不那么脆弱”。我说：“我认为我的测试需要非常简单明了，这意味着我的代码需要重复”。他说，“不要把你的测试代码写成与你的生产代码有任何不同，让它们保持干燥（不要重复自己）”。

然后，这引发了一整类关于我的程序的元问题。什么是足够的测试代码？什么是好的测试代码？

我最终意识到，当我编写大量极其简单和重复的测试时，我花在重构测试上的时间比编写新代码的时间还要多。大量重复的测试代码很脆弱。它并没有阻止错误，而是使添加功能或消除技术债务变得更加困难。在业务逻辑方面，代码越多，价值就越大。同样，当重构它成为“测试债务”时，更冗长的测试代码也无济于事。

This then leads to another big point: loosely typed languages, that need lots of unit tests to prove are correct, need lots of brittle and repetitive tests. Strongly typed languages, where the compiler can statically tell you about logic errors, means you have to write a less test code, that is less brittle, such that you can refactor faster. In a loosely typed language you end up writing lots of test code that makes sure at runtime you don’t pass the wrong types. In a strongly typed function language you only need to validate input at runtime: the compiler validates that your code works. So then you can write a few high level tests and be confident it all works. If you refactor your code you have less tests to refactor. You have tagged your question “language-agnostic” but the answer cannot be. The weaker your compiler the more this question is a problem: the stronger your compiler the less you have to deal with this whole issue.

I attended a four day test driven development course at a big software engineering shop that was done in Smalltalk. Why? Because no-one knows smalltalk, and it is untyped, so we had to write a test for every thing we wrote as we were all beginners in that language. It was fun, but I wouldn’t advise anyone to use a loosely typed language where they had to write a load of tests to know it worked. I would strongly advise people to use a strongly typed language where the compiler does more work, and where there can be less test code, as that is easier to refactor tests when you add new functionality. Likewise functional languages with immutable algebraic types and composition of functions need less tests as they don't have lots of mutable state to worry about. The more modern the programming language the less test code you need to write to keep bugs away.

Obviously, you cannot upgrade the language you are using at your company. So here is the one tip my friend said that sticks with me: test code should be like production code so do not repeat yourself. If you find your tests are becoming repetitive then delete tests. Keep a minimum amount of tests that will break if the logic is broken. Don't keep fifty odd tests that cover all variations of string concatenation. That is ”over-testing” Over-testing inhibits refactoring to add functionality and remove tech debt more than it keeps bugs away. In some languages, this means writing lots of repetitive tests that you need to validate your logic as you write it as scaffolding. Then when you have it working write larger tests that will break if someone breaks a subparts and delete all the repetitive tests so as not leave ”test debt”. This then results in a few coarse-grained tests that are brutally simple without a lot of repetition.