使用 nhibernate 在 .net 中进行集成测试

Question

我一直在为我的最新项目做一些诚实的 TDD，我很喜欢它，以前做过单元测试但不是认真的 TDD，我发现它很有帮助。

我的项目的一些背景：

• ASP.Net 前端-
• NHibernate 用于与 SQL Server 2008 express 进行数据库交互-
• 用于在 NUnit 中完成并通过 resharper 运行的域逻辑和单元测试的 C# 4.0 DLL。
• 运行 NAnt 构建脚本的 Teamcity CI 服务器。

我现在处于某种“alpha”版本，我发现所有错误都是集成错误，主要是因为我的集成测试是手动使用网站，以及一些小的自动化测试（我已经停止跑步）。考虑到我对测试套件的严格程度以及我想要纠正它，这非常糟糕。

我的问题是，进行集成测试的最佳方法是什么，或者我可以阅读任何文章。我知道在 ASP.NET Webforms 中测试 UI 将是一件痛苦的事情（将来会转移到一个更可测试的框架，但一次一步）。但我想确保我与 hibernate 的交互得到了正确的测试。

所以我需要一些关于集成测试的技巧

• 休眠（缓存、会话等）-
• 测试数据，我发现 'NDBUnit' 是我应该考虑使用什么来使我的数据处于良好状态？这与 NHibernate 兼容吗？
• 我应该将数据库换成 SQLite 还是什么？或者只是设置另一个仅保存测试数据的 SQL 服务器数据库？
• 如何使这些测试可维护？我进行了一些集成测试，但它们给我带来了麻烦，我发现自己避开了它们。我认为这主要是由于我没有每次都设置一致的状态。

只是一些一般性的建议也很好，我已经阅读了 Kent Beck 的 TDD 示例和 Roy Osherove 的单元测试艺术，它们非常适合单元测试/tdd，但我很想阅读更多关于集成测试和编写它们的策略（你应该测试什么等）---

Answer 1

关于数据库部分：
- 您可以直接按照本文所述使用它：Unit testing with built-in NHibernate support.
- 使用 SQLite 加速测试也非常有用。只有在这种情况下，您应该意识到您不再真正针对实际生产配置。
- SQLite 不支持 SQL Server 支持的所有功能。 This article 显示了切换到 SQLite 所需的测试设置的代码示例 - 它非常简单直接。
- NDbUnit 作为一种准备测试数据的机制也是一个不错的选择 - 只要您不希望在您的 Db 上频繁更改架构（在这种情况下，维护所有相关的 xml 会变得相当多的工作文件...）。
关于 ASP.NET 部分：
- 您可能会发现像 Selenium 这样的工具对 UI 驱动的测试很有帮助。

HTH！
托马斯

Answer 2

聚会有点晚了，但这是我一段时间以来一直在做的事情。

我正在编写 REST API，供我们的移动应用使用。移动应用程序也是用 C# 编写的，因此编写 API 包装器 (SDK) 对我来说很有意义。

在集成测试时，我设置了测试用例来测试 API 的所有端点，使用 SDK。运行测试时，API 在我的本地 IIS 上以开发模式运行。每次启动服务器时，我的开发数据库都会被擦除、重新创建并为所有表添加数据，这给了我一个有点现实的场景。我也不必担心测试更新/删除，因为只需要重建服务器项目，NHibernate 将删除、创建和播种我的数据库。如果需要，这可以更改为每个请求。

在测试我的存储库时，了解我的查询是否可以被 NHibernate 翻译对我来说很重要，因此我所有的存储库测试都使用 LocalDB，每个测试用例都会重新创建它。这意味着每个测试用例都可以设置查询测试成功所需的种子数据。

另一件事，当您使用真实数据为您的数据库播种时，您还可以免费测试您的外键设置。此外，播种器正在使用您的域类，所以看起来也不错！

播种机示例：

public void Seed(ISession s) 
{
  using(var tx = s.BeginTransaction() 
  {
    var account1 = new Account { FirstName = "Bob", LastName = "Smith" };
    var account2 = new Account { FirstName = "John", LastName = "Doe" };
    account1.AddFriend(account2); // manipulates a friends collection
    s.Save(account1);
  }
}

您应该在创建会话工厂时调用播种器。

重要提示：设置是通过 IoC 容器完成的。

Answer 3

简短的回答是：不要进行集成测试。

我们有以下设置：

• 我们的单元测试尽可能少地测试。我们只测试业务代码的一个功能（不是直接的方法，而是更多的逻辑功能）；

• 为业务代码的每个功能编写单元测试；

• 为业务代码的不同功能之间的交互编写单元测试；

• 确保这些测试涵盖所有内容。

这将为您提供一组涵盖所有内容的单元测试。

我们确实有集成测试，但这些测试是写在 Word 文档中的，而且通常只是原始规范。 QA 人员会在代码交付时运行这些程序，并且大多数情况下它只是正常工作，因为我们已经测试了每一个小部分。

在 InfoQ 上，有一个很棒的演示文稿很好地解释了这种工作方式：Integration Tests Are a Scam。

关于测试 NHibernate 的一件事。我们已经申请了repository pattern。这样做是我们的 NHibernate 查询变得非常非常简单，例如：

public class NhRepository<T> : IRepository<T>
{
    public T Get(int id)
    {
        return GetSession().Get<T>(id);
    }
}

public interface IUserRepository : IRepository<User>
{
    IEnumerable<User> GetActiveUsers();
}

public class UserRepository : NhRepository<User>, IUserRepository
{
    public IEnumerable<User> GetActiveUsers()
    {
        return
            from user in GetSession().Users
            where user.IsActive
            return user;
    }
}

这与Windsor IoC 容器相结合提供了我们的数据访问。这个设置的问题是：

1. 查询非常简单（无论如何，其中有 98%），我们没有彻底测试它们。这听起来可能很奇怪，但我们更倾向于使用同行评审来测试这些，而不是任何其他机制；

2. 这些存储库很容易被模拟。这意味着对于上面的存储库，我们有一个类似这样的模拟：

   var repositoryMock = mocks.StrictMock<IUserRepository>();
   
   var activeUsers = new List<User>();
   
   for (int i = 0; i < 10; i++)
   {
       var user = UserMocks.CreateUser();
       user.IsActive = true;
       activeUsers.Add(user);
   }
   
   Expect.Call(repositoryMock.GetActiveUsers()).Return(activeUsers);
   

   实际的代码要简洁得多，但你明白了。