集成测试私有类和方法
对于单元测试，您不应该测试私有方法，是的，但是对于集成测试（使用 MSTest 或 NUnit 等单元测试框架），我非常希望针对测试 url 运行内部 API 调用，以确保当前代码当第三方 API 供应商更改其后端时有效。
考虑到系统的复杂性（愚蠢的 API 有数百个参数），我将大部分隐藏在接口和 IoC 后面，API 帮助器类完全位于我们的数据层库内部。我不想改变这一点，因为它曾经是公开的，而且我们发现奇怪的开发人员刚接触该项目且缺乏经验，通常会立即直接从网站代码调用 api。将类设为内部应该确保它们至少在破坏我们的抽象层的点之前进行思考。
我一直在构建大量的反射代码来获取内部方法，但它运行得不太好，而且越来越像意大利面条。有没有办法使某些库的方法公开可见？有没有办法让测试库将自己视为包含 api 的库的一部分？这是最佳实践吗？
For unit testing you shouldn't test private methods, yes, but for integration tests (using a unit testing framework like MSTest or NUnit) I would very much like to run the internal API calls against a test url, to make sure the current code works when the third party API vendor changes their backend.
Given the complexity of the system (stupid API's have hundreds of parameters) I have hidden most of it behind interfaces and IoC, with the API helper class completely internal to our data layer library. I don't want to change this because it used to be public and we found the odd developer new to the project and inexperienced in general would promptly go ahead and call the api directly from website code. Making the class internal should ensure that they at least think before destroying the point of our abstraction layer.
I've been building up a mass of reflection code to get at the internal methods, but it is not working too well and is getting sphagetti-ish. Is there a way to make the methods publically visible for certain libraries? Is there a way to get the test libray to treat itself as part of the library containing the api? Is any of this best practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
InternalsVisibleTo 属性 是您的朋友 =)如果将其放置在 AssemblyInfo.cs 中（至少是我通常放置的位置）并指定您希望公开内部方法的测试/其他程序集的名称，那么它们就可用。额外的好处（至少在我看来）是 Visual Studio 的智能感知系统/编译器知道该属性及其用途，并且您将为内部方法提供完整的智能感知。
与反射不同的是，每当您更改内部方法签名时，它都不会严重破坏，而不会提供编译时错误。
The InternalsVisibleTo attribute is your friend here =) If you place it in the AssemblyInfo.cs (at least that's where I usually put it) and specify the name(s) of the test/other assemblies you wish to expose internal methods to, they're then available. The added bonus (at least to my mind), is that Visual Studio's intellisense system / compiler is aware of the attribute and its purpose and you'll have full intellisense provided for the internal methods.
And unlike reflection it won't break horribly without providing a compile-time error whenever you change the internal methods signature.