关于c＃：NUnit测试应用程序，而不是环境或数据库


NUnit testing the application, not the environment or database

我想更好地使用NUnit来测试我编写的应用程序，但我经常发现我编写的单元测试有一个直接链接到开发机器上的环境或底层数据库。

让我举个例子。

我正在编写一个单独负责重写字符串的类，该字符串已由另一个应用程序存储在注册表中。密钥存储在HKCU Software CustomApplication IniPath中。

我最终写的测试看起来像这样;

1
2
3
4
5
6
[Test]
public void GetIniDir()
{
    RegistryReader r = new RegistryReader();
    Assert.AreEqual(@"C:\Programfiles\CustomApplication\SomeDir", r.IniDir);
}

但问题是字符串@"C： Programfiles CustomApplication SomeDir"现在真的是正确的。明天它可能已经改为@"C： Anotherdir SomeDir"，突然间，即使代码没有改变，也会破坏我的单元测试。

当我创建一个对数据库执行CRUD操作的类时，也会出现此问题。数据库中的数据可以随时更改，这反过来会使测试失败。因此，即使我的类完成了预期的操作，它也会失败，因为数据库会返回我最初编写测试时所拥有的更多客户。

1
2
3
4
5
6
[Test]
public void GetAllCustomersCount()
{
    DAL d = new DAL();
    Assert.AreEqual(249, d.GetCustomerCount());
}

你们有没有关于编写不依赖周围环境的测试的技巧？

这个问题的解决方案众所周知：嘲弄。将代码重构为接口，然后开发假类来实现这些接口或使用模拟框架模拟它们，例如RhinoMocks，easyMock，Moq等。人。使用伪类或模拟类允许您定义接口为测试返回的内容，而无需实际与外部实体(如数据库)进行交互。

有关通过SO进行模拟的详细信息，请尝试以下Google搜索：http：//www.google.com/search？q = mock + site：stackoverflow.com。您可能也会对以下定义感兴趣：伪造，嘲弄和存根之间的区别是什么？

此外，良好的开发实践，例如依赖注入(如@Patrik建议)，允许将类与其依赖项分离，以及避免静态对象，这使得单元测试更加困难，将有助于您的测试。使用TDD实践 - 首先开发测试 - 将帮助您自然地开发包含这些设计原则的应用程序。

最简单的方法是使用依赖注入使依赖项显式化。例如，您的第一个示例依赖于注册表，通过传递IRegistry(您将定义的接口)实例使该依赖项显式化，然后仅使用此传递依赖项从注册表中读取。这样，您可以在测试时传入IRegistry-stub，并始终返回已知值，而在生产中，您可以使用实际从注册表中读取的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public interface IRegistry
{
    string GetCurrentUserValue(string key);
}

public class RegistryReader
{
    public RegistryReader(IRegistry registry)
    {
        ...
        // make the dependency explicit in the constructor.
    }
}
[TestFixture]
public class RegistryReaderTests
{
    [Test]
    public void Foo_test()
    {
        var stub = new StubRegistry();
        stub.ReturnValue ="known value";

        RegistryReader testedReader = new RegistryReader(stub);

        // test here...
    }

    public class StubRegistry
        : IRegistry
    {
        public string ReturnValue;

        public string GetCurrentUserValue(string key)
        {
            return ReturnValue;
        }
    }
}

在这个快速示例中，我使用手动存根，当然您可以使用任何模拟框架。

您应该阅读控制原理的反转以及如何使用依赖注入技术 - 这真的可以帮助您编写可测试的代码。

在你的情况下，你应该有一个接口 - 例如IIniDirProvider - 由RegistryBasedIniDirProvider实现，它可以根据注册表中的特定密钥提供初始目录。

然后，当其他一些类需要查找初始目录时，该另一个类应该具有以下ctor：

1
2
3
4
public SomeOtherClass(IIniDirProvider iniDirProvider)
{
    this.iniDirProvider = iniDirProvider;
}

- 当你需要单元测试SomeOtherClass时，你要传递一个模拟IIniDirProvider。这样，您的单元测试将不依赖于注册表中存在的任何内容。

其他方法是为测试创建单独的数据库。

相关讨论