使代码内部但可用于其他项目的单元测试

Question

使代码内部但可用于其他项目的单元测试

leo*_*ora 123 c# unit-testing scope

我们将所有单元测试都放在他们自己的项目中.我们发现我们必须将某些类公开而不是内部仅用于单元测试.无论如何都要避免这样做.通过将类公开而不是密封来实现内存含义是什么？

Answer 1

Ash*_*Ash 197

如果您使用的是.NET,则InternalsVisibleTo程序集属性允许您创建"朋友"程序集.这些是特定的强名称程序集,允许访问内部类和其他程序集的成员.

请注意,这应该谨慎使用,因为它紧密耦合相关的组件.InternalsVisibleTo的常见用途是用于单元测试项目.由于上述原因,它可能不适合在您的实际应用程序集中使用.

例:

[assembly: InternalsVisibleTo("NameAssemblyYouWantToPermitAccess")]
namespace NameOfYourNameSpace
{

Run Code Online (Sandbox Code Playgroud)

我建议在属性周围加一个#if DEBUG,然后在debug中进行单元测试.这样你就可以确保该属性不是在发布代码上设置的. (19认同)
不同意.如果我使用非常薄的公共API构建复杂组件,那么仅通过公共API进行测试是不切实际且不切实际的.你最终会得到一个无法维持的泥球.相反,我会仔细定义内部单元并单独测试它们.正如杰里米·D·米勒(Jeremy D. Miller)经常说的那样:"在你考试之前测试一下". (7认同)
对于 .NET Core - 将 `InternalsVisibleTo` 添加到应用程序中的任何 .cs 文件中。请参阅此处的详细信息 - /sf/answers/2956490421/ (5认同)
那么,为什么限制测试来调试构建呢？ (4认同)
此外,只是一个挑剔,没有必要强烈命名"朋友"集会(可能是一个很好的做法 - 即使我个人的口味否则,但不是强制性的). (2认同)

Answer 2

小智 18

以下是在.NET Core应用程序中使用的方法。

添加AssemblyInfo.cs文件并添加[assembly: InternalsVisibleTo("AssemblytoVisible")]
将其添加到.csproj文件（包含内部类的项目）中

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
    <_Parameter1>Test_Project_Name</_Parameter1> <!-- The name of the project that you want the Internal class to be visible To it -->
  </AssemblyAttribute>
</ItemGroup>

Run Code Online (Sandbox Code Playgroud)

欲了解更多信息，请关注https://improveandrepeat.com/2019/12/how-to-test-your-internal-classes-in-c/

Answer 3

Jos*_*osh 6

如果它是一个内部类,那么它不能被孤立地使用.因此,除了测试在内部使用该对象的其他类之外,您不应该真正测试它.

正如您不应该测试类的私有成员一样,您不应该测试DLL的内部类.这些类是一些可公开访问的类的实现细节,因此应该通过其他单元测试来很好地执行.

这个想法是你只想测试一个类的行为,因为如果你测试内部实现细节,那么你的测试将是脆弱的.您应该能够在不破坏所有测试的情况下更改任何类的实现细节.

如果您发现确实需要测试该类,那么您可能想要首先重新检查该类为什么是内部的.

我不一定同意这一点,因为这些类对DLL内的其他类是"公开的",并且该类的功能应该是独立测试的 (67认同)
我也不同意.单位是单位,必须单独测试. (27认同)
伟大的一般准则,但让我们不要教条.测试有两个主要目的:1)回归 - 确保你没有破坏某些东西,2)提高开发速度.如果每次我想编写一行代码时我都必须提供大量服务,那么我将阻碍开发.如果我有一个复杂的内部部分,我希望能够孤立地开发和测试.相反,我不希望所有测试都被隔离(因此降低了回归测试值,或重复测试代码),但有些代码证明了隔离.也许关键是要使它成为一个单独的组件. (5认同)
实施细节应作为综合测试的一部分进行。不要偷看私有变量...测试预期行为。如果测试正确……所有内部管道和接线都应作为测试的一部分进行测试。投票了。 (2认同)
OP在这里是正确的。您正在将测试耦合到内部实现。因此，您的团队永远是修补测试和可怕的模拟代码的奴隶。仅测试公共API，无论是打包的lib API还是网络公开的API。所有代码应可通过前门执行。测试实现是TDD在很大程度上消失的原因，它实际上是测试整个应用程序的每个类的巨大PITA，而不是专注于确保系统行为。我认为几乎每个人，包括“权威”书籍，都犯了这个错误或没有弄清楚。 (2认同)

归档时间：	17 年，5 月前
查看次数：	55466 次
最近记录：	7 年，7 月前