集成测试私有类和方法 [英] Integration testing private classes and methods

查看:101
本文介绍了集成测试私有类和方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于单元测试,您不应测试私有方法,是的,但是对于集成测试(使用诸如MSTest或NUnit之类的单元测试框架),我非常想针对测试url运行内部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.

考虑到系统的复杂性(愚蠢的API有数百个参数),我将其大部分隐藏在接口和IoC后面,而API帮助程序类完全位于我们的数据层库内部.我不想更改它,因为它以前是公开的,我们发现该项目的新开发人员奇怪且通常没有经验,会立即着手直接从网站代码中调用该api.将类设置为内部应该确保他们至少在破坏我们的抽象层的点之前进行思考.

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.

我一直在构建大量的反射代码来了解内部方法,但是它工作得不太好,并且变得有点乱七八糟.有没有办法使某些库对这些方法公开可见?有没有办法让测试库将自身视为包含api的库的一部分?这是最佳实践吗?

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?

推荐答案

InternalsVisibleTo属性是您的朋友=)如果将其放在AssemblyInfo.cs中(至少是我通常放置的位置),并指定测试/其他程序集的名称,希望公开内部方法,然后可以使用它们.额外的好处(至少在我看来)是Visual Studio的intellisense系统/编译器知道该属性及其用途,并且您将为内部方法提供完整的intellisense.

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.

这篇关于集成测试私有类和方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆