我也在MSDN论坛上问过这个问题,但没有找到解决方案:

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3686852&SiteID=1

我认为这里的基本问题是互操作程序集实际上不包含任何可以检测的 IL(可能除了一些委托之外)。因此,虽然我可以组合一个测试项目来练习互操作层,但我无法理解 多少 我实际调用的那些方法和属性。

B 计划是编写一个代码生成器,该生成器创建一个 RCWW(运行时可调用包装器)库,并对其进行检测以实现代码覆盖率。

编辑:@弗朗西·佩诺夫,

是的,这正是我想做的。交付给我们的 COM 组件构成了一个包含大约 12 个 DLL 的库。3000种。我们在应用程序中使用该库,并负责测试该互操作层,因为向我们提供库的团队只进行了最少的测试。代码覆盖率将使我们能够确保所有接口和组件类都得到执行。这就是我想做的一切。我们有单独的测试项目来运行我们自己的托管代码。

是的,理想情况下,COM 服务器团队应该测试和分析他们自己的代码,但我们并不生活在一个理想的世界中,我必须根据他们的工作交付高质量的产品。如果可以生成一份测试报告,表明我已经测试了他们 80% 的代码接口,并且其中 50% 的代码接口无法按照广告宣传的那样工作,那么我可以在需要修复的地方进行修复,而不是解决问题。

你提到的模拟层会很有用,但最终不会实现测试互操作层本身的目标,而且我当然不想手动维护它——我们在术语上受到 COM 人员的摆布接口的更改。

正如我上面提到的,下一步是为包装器生成包装器并对其进行测试以进行测试。

有帮助吗?

解决方案

要回答您的问题 - 不可能对互操作程序集进行代码覆盖率检测。正如您自己提到的,它们仅包含元数据,并且不包含可执行代码。

此外,我认为尝试对互操作程序集进行代码覆盖没有太多意义。您应该测量您编写的代码的代码覆盖率。

从您提到的 MDN 论坛主题来看,在我看来,您实际上想测量代码如何使用 COM 组件。除非代码的目标是枚举并显式调用 COM 对象的所有方法和属性,否则不需要测量代码覆盖率。您需要单元/场景测试来确保您的代码在正确的时间调用正确的方法/属性。

恕我直言,正确的方法是为 COM 对象编写一个模拟层,并测试您是否按预期调用所有方法/属性。

其他提示

C计划:

使用类似的东西 莫诺·塞西尔 将简单的执行计数器编织到互操作程序集中。例如,查看以下部分 常问问题:“我想向无法调试的程序集添加一些跟踪功能,可以使用 Cecil 吗?”

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top