我正在考虑使用反射进行单元测试，其中将比较 2 个对象的相等性，并且将广泛使用 GetProperties() 和 GetFields() 方法。但是，我知道性能影响将非常显着。事实上，我的几个同事使用反射将某些源对象深层复制到目标对象。该代码绝对优雅、美观并且完全按照其预期执行。问题是他们不得不废弃它，因为它真的很慢。那么，在单元测试中使用反射会导致一切都失败吗？或者有没有一种方法可以在不造成可笑的性能影响的情况下实现它？预先非常感谢。
I was thinking about using reflection for unit tests where 2 objects will be compared for equality and GetProperties() and GetFields() methods will be used extensively. However, I know that the performance impact will be very significant. In fact, couple of my coworkers used reflection for a deep copy of some sourceobject to targetobject. The code is absolutely elegant, beautiful and does exactly what it's supposed to do. The problem is they had to scrap it because it was really slow. So, is all lost when it comes to using reflection in unit tests or is there a way to implement it without a ridiculous performance hit? Thanks a lot in advance.
发布评论
评论（5）
您可以查看 HyperDescriptor ，与反射相比，它可以加快速度。
You may take a look at HyperDescriptor which could speed things up compared to reflection.
查看 AutoFixture 的 相似。它的作用正是您上面所描述的。然后您可以测试您是否认为性能可以接受。
有关用法示例，请参阅另一个问题： 如何在单元测试中比较两个对象？
Check out AutoFixture's Likeness. It does exactly what you describe above. Then you can test whether you find the performance acceptable.
See this other question for an example of usage: How to Compare two objects in unit test?
如果你没有测量，你就不会知道这一点。您可能会怀疑...
避免反射成本的最简单方法是使用反射来生成单元测试。那么单元测试本身就没有反射。
If you don't have measurements, you don't know that. You might suspect it...
The simplest way to avoid reflection costs is to use reflection to generate the unit test. Then the unit test has no reflection itself.
您的单元测试必须运行多快？解决方法（避免反射）是否可以更好地利用您的时间来节省一些单元测试时间？
您现在的测试需要多长时间？在使用反射实现单元测试之前，您将不知道它们到底有多快（或多慢），并且无法比较替代方案。
How fast do your unit tests have to run? Is a work around (avoiding reflection) a better use of your time to save some unit test time?
How long do your tests take right now? Until you implement your unit tests using reflection you will not know how fast (or slow) they really are, and will not be able to compare the alternatives.
一种方法是尝试加速反射调用。鉴于您依靠低级机制来完成此任务，我在这里看不到太多希望。
另一种方法是支付成本，但仅在再次需要测试时才支付。 （如果不更改正在测试的代码，则无需再次测试）。
我们的C# 测试覆盖率工具可以跟踪（抽象测试）和测试的代码。它可以通过检查更改代码的覆盖范围来确定是否需要再次运行（抽象）测试，这是通过在方法级别比较代码文件来确定的。如果存在交叉点，则需要再次运行（抽象）测试。否则，您可以简单地跳过这些测试以及它们可能包含的任何昂贵的开销（“反射”）。
狡猾的词“抽象测试”只是意味着您定义哪组测试活动对应于可检测的可重测试单元；您可以决定跟踪每个单元测试，或以其他方便的方式对它们进行分组。理想情况下，您希望获得最精细的抽象测试，以最大程度地减少实际的重新测试；有时最好将一组测试集中在一起。
One approach is to try to speed up reflection calls. Given that you are leaning on the low-level machinery to accomplish this, I don't see a lot of hope here.
Another approach is to pay the cost, but only pay it when testing is again necessary. (If you don't change the code being tested, you don't need to test it again).
Our C# Test Coverage tool can keep track of the relationship between (abstract tests) and the tested code. It can determine whether an (abstract) test needs to be run again by examining its coverage with respect to changed code, which it determines by comparing code files at the level of methods. If there's an intersection, you need to run the (abstract) test again. Otherwise you can simply skip those tests, and any expensive overhead ("reflection") they might contain.
The weasel words "abstract test" just means that you define what set of test activities corresponds to detectably retestable unit; you can decide to track every unit test, or group them in other convenient ways. Ideally you want the finest grain abstract tests you can get to minimize actual restesting; sometimes it is better to just lump a group of tests together.