NHibernate存储库的单元测试策略

Question

我在一个相当大的项目上使用NHibernate和Repository模式，并试图建立我的服务层单元测试策略，但遇到一些麻烦。 我可能不正确地进行单元测试，也有可能我不正确地进行了存储库模式，但是我不确定是哪个。

我的方案的简化子集如下所示：

public class UserRepository : RepositoryBase, IRepository 
{

   public UserRepository() {}
   public UserRepository( ISession sessionParam ) {
      session = sessionParam;   // member of repository base
   }

   public string GetUsernameFromEmail( string emailAddress ) {
      return session.QueryOver<Members>().List().Where( u => u.EmailAddress.ToLowerInvariant() == emailAdrress.ToLowerInvariant() ).FirstOrDefault().Username;
   }

}

我的单元测试概念是，我将伪造NHibernate的ISession并传递一个返回的用户列表，该列表适合我要测试的场景（例如，电子邮件地址不区分大小写）（我也不能让它与FakeItEasy一起使用，但这是另一个问题，我应该沿着这条道路走吗？ 请记住，我们不应该伪造我们不拥有的对象，我可以看到不想伪造ISession的逻辑，而且我已经读了很多关于如何不应该测试存储库的知识-那也是进行单元测试的时间很短。

但是即使在这种非常基本的情况下，我也想对存储库中的逻辑进行单元测试。 其他存储库方法可能具有甚至更多的逻辑（例如，数据验证等）。 我知道我可以使用SqlLite或类似的东西为资源库建立相对快速的集成测试，但是在我看来，这种逻辑仍然应该进行单元测试。

依靠存储库，Asp.Net MVC4站点正在使用（WCF）服务层。

在所有方面最好的情况下，我将在WCF层中构建单元测试，并伪造IRepository进行测试，但是我看不到如何在不从存储库中获取所有用户的情况下将该逻辑移至服务层。将它们返回到服务层，这似乎很可笑。

所以我的问题是：我在这里总体上哪一部分根本上错了？

编辑

为了回应@ Wiktor-zychla的回答，这是我为什么要伪造ISession的逻辑。 在考虑此特定测试时，我想让我的存储库使用ISession的实现，该实现始终返回具有混合大小写电子邮件地址和特定用户名的单个用户，传递所有小写的电子邮件地址并返回value是我指示我的假货使用的用户名。 这样一来，我就可以根据一个已知值来测试我的逻辑-不管那不是NHibernate在现实世界中的运行方式，这里我都不关心-测试存储库方法中的逻辑。 再说一次，我知道这是一个琐碎而幼稚的示例，可以通过许多其他方式解决-它只是代表了更复杂的功能，我希望以后可以进行测试。

Answer 1

我认为您不应该尝试伪造ISession。 这没有多大意义-NHibernate存储库是抽象概念的具体实现，您要测试的是，这个具体实现是否可行，而不是进一步抽象并测试什么？ 一个不同的伪造linq实现，然后假装NH遵循它吗？

然后，您的单元测试应该包含一个真实的数据库，可能要在测试开始之前进行设置，以便您将临时ISession注入存储库，但ISession仍然指向真实数据库。

另一方面，在测试使用存储库的服务时，将存储库的另一种实现注入服务层是完全有效的。