AssemblyInitialize 未在代码覆盖率中进行测量
在使用代码覆盖率进行单元测试时，我遇到了一些奇怪的结果。
在AssemblyInitialize函数中，我们做了一些初始化工作（如AutoMapper、AbstractFactories），并且该函数被正确执行。
奇怪的是，代码覆盖率显示没有覆盖从 AssemblyInitialize 调用的函数。这是设计使然还是我在这里做错了什么？
I came across some strange results when using Code Coverage for our unit tests.
In the AssemblyInitialize function we do some initialization work (like AutoMapper, AbstractFactories) and this function is correctly executed.
The strange thing is that Code Coverage shows that there is no coverage for the functions that are called from AssemblyInitialize. Is this by design or am I doing something wrong here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会选择按设计，它似乎太具体了，不能是其他任何东西。作为一个正在寻求对开源覆盖工具进行类似操作的人，这似乎很奇怪，因为这是一次意外，而且是一个非常不寻常的错误。
我内心的 TDD 纯粹主义者会说这是因为任何类型（程序集/类）的设置/拆卸实际上并不是测试本身的一部分，因此不应包含在覆盖范围内。相反，您应该对该代码进行单独的特定测试，而不是依赖于测试设置/初始化失败。
其他 .NET 工具（例如 dotCover）会通过测试进行覆盖，并且“可能”还会排除同时获得的结果运行此类设置；但这只是推测，而不是已知的事实。
I would go with as by-design it seems too specific to be anything other. As someone who is looking into doing similar for an open source coverage tool it seems odd for this to be an accident and would be a very unusual bug.
The TDD purist in me would say this is because the setup/teardown of any type (assembly/class) is not actually part of the test itself and so should not be included in coverage. You should instead have separate, specific tests for that code rather than rely on the test setup/initialization failing.
Other .NET tools (dotCover for one) does coverage by test and 'may' also exclude results gained whilst running such setups; this is conjecture rather than known fact though.