我正在努力将尽可能多的逻辑移出自定义控件，以便它可以进行单元测试以减少手动测试负担。我遇到了一种情况，即被测方法产生复杂的结果。编写一个计算结果的测试用例将涉及将基本上是被测代码写入测试本身。如何编写需要重复测试代码的代码测试？
例如，我有一个GeometryGenerator类，该类根据类的属性创建WPF几何。在一种配置中，生成由ArcSegment组成的PathGeometry。我可以根据测试参数计算弧的属性，但是这个计算与我试图测试的代码是一样的。这似乎会使测试失效;如果计算中存在缺陷，则测试中会存在缺陷，如果计算发生变化，则可能在测试中更改。
我该如何处理这种情况？我想出的唯一方法是手动计算测试用例的结果并将这些值硬编码到测试中。这是一个可以接受的方法吗（看起来像我在执行之前编写测试时所做的一样）？
我想出的唯一方法是手动计算测试用例的结果并将这些值硬编码到测试中。这是一个可以接受的方法吗（看起来像我在执行之前编写测试时所做的一样）？
是的，这是典型的。为了进行单元测试，您必须假定您用来计算结果的公式是正确的。这是您正在测试的软件实施。
您预先计算了一些手工计算的结果，以确保您没有使用测试代码生成测试数据（单元测试中的一个非常糟糕的错误）。只要确保记录测试用例，以便知道预期值代表什么以及它们来自哪里。
“单元测试”应该只是测试一个单元。所以最好你将有单独的单元测试你的GeometryGenerator，另一个用于PathGeometry类，第三为您ArcSegment等
通过测试每个单元seperately，你能获得某种信心关于他们将如何表现当你用给定的一组输入调用给定的操作时（GeometryGenerator在ArcSegment中的字段被设置为1时的行为方式，当相同字段被设置为0时的行为方式等）。
如果你的单元测试开始看起来像你正在复制现有的代码来测试某些功能，那么恐怕你正在做单元测试错误，并且有一个更简单和更有效的解决方案。
手工计算和硬编码在生产代码中是不好的，但是对于良好的单元测试是必不可少的。
您通常希望为代码的每个“状态”编写一个测试。例如，我经常用正输入，负输入和零输入编写测试，以确保代码正常工作。
通常情况下，我会做出一个神奇的数字，自文件，但被硬编码，就像
const int的expectedResult = 2 * 4/someConstant; //也许是一个评论。
测试的读者可以推断出这些值是什么，或者如果需要可以添加额外的注释。