关于单元测试：在C＃中测试/注入私有字段的好习惯是什么？


What are the good practice to test/inject private field in C#

如果这个重复，我道歉。 我被赋予了为该方法添加一些覆盖的任务，并被告知模拟私有List属性。 我的问题是：有没有办法测试私有字段？

我找到的解决方案是添加新的构造函数只是为了注入这个私有列表。 我不确定这是否正确，所以任何帮助都将受到高度赞赏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Class1
{
    public Class1(List<string> list)//This is just for Unit Testing
    {
        list1 = list;
    }


    private readonly InjectRepository _repository;
    //
    public Class1(InjectRepository repository)//This is the actual constructor
    {
        _repository = repository;
    }

    private List<string> list1 = new List<string>();

    public void Do_Complex_Logic()
    {
       //list1 will be set with items in it
       //Now list1 is passed to some other instance
    }
}
相关讨论

不要测试私有字段或方法。测试合同的行为 - 公共或内部方法。

那说，你可以尝试：

选项A
使私有成员内部并为要测试的程序集设置InternalsVisibleTo属性。

选项B
编写一个包装类，将私有字段/方法包装到公共字段/方法中。这种方法的好处是您不需要将私有方法设置为内部方法。缺点是，对于每个私有方法，您将拥有一个包装器公共方法。所以方法的数量可能会翻倍。

类的私有逻辑应该在其行为的公共表达中可见。换句话说，理论上说，根本不需要测试私有字段。

无法直接测试私有字段;毕竟他们是私人的。如果您真的认为需要测试私有字段，那么我建议将其设置为内部，并通过[InternalsVisibleTo]属性将其公开给您的单元测试程序集。

话虽这么说，有些框架允许这样的事情，比如TypeMock。

添加到womp＆oleksii已经说过 -

您希望/需要测试私有方法的事实是一个标志(气味？)，您的设计可能不正确。这是TDD(以及我个人最喜欢的)的积极副作用之一。

一个例子：

我在这里并不完全了解您的域名，但是一个简单的更改可能是，而不是Do_Complex_Logic不带参数，您可以使用并返回List：

public List Do_Complex_Logic( List input )

我知道 - 这很简单，但是请尝试解构一下你的课程，然后首先考虑测试。

相关讨论

私人领域如何在第一时间做好准备？如果是通过与存储库的交互，那么您可能会模拟该对象。

一种方法是通过接口与您的存储库进行交互(让我们称之为IInjectRepository而不是具体实体，然后使用像Moq(或许多模拟框架中的一个)之类的东西来填充您的数据在设置测试时使用模拟存储库。在调用Do_Complex_Logic之后，我假设您有一种询问实体的方法，以便您知道它已经完成了您的预期。这样您就可以避免/减轻添加方法和仅供测试的类。

我不同意其他答案;但在这种情况下，我认为最合适的事情是 - 给出你的代码;是改变签名

'Do_Complex_Logic'

真正的问题是你正在处理List1的'状态'。如果将List1传递给Do_Complex_Logic - 您的问题基本上已得到解决。您的评论说'Do_Complex_Logic'将(可能)在List1上做一些工作，然后将其传递给其他东西，对吧？

使Do_Complex_Logic获取List并返回List。现在很容易测试。您可以"注入依赖项"，而不是依赖于在类中正确设置List1的状态。

您可以在回答相关问题的https://stackoverflow.com/a/3376157/1523402中使用反射。
我不知道私人访问者是否也适用于私人领域。但它们(至少)帮助私有方法(请参阅http://msdn.microsoft.com/en-us/library/ms184807%28v=vs.80%29.aspx)。