这是我非常感兴趣的一个话题。有很多纯粹主义者说你不应该测试 EF 和 NHibernate 等技术。他们是对的，他们已经经过了非常严格的测试，正如之前的回答所说，花费大量时间测试你不拥有的东西通常是没有意义的。
但是，您确实拥有下面的数据库！这是我认为这种方法失败的地方，您不需要测试 EF/NH 是否正确地完成了他们的工作。您需要测试您的映射/实现是否与您的数据库一起使用。在我看来，这是您可以测试的系统中最重要的部分之一。
然而，严格来说，我们正在走出单元测试领域并进入集成测试领域，但原则保持不变。
您需要做的第一件事是能够模拟您的 DAL，以便您的 BLL 可以独立于 EF 和 SQL 进行测试。 这些是你的单元测试。接下来你需要设计你的集成测试来证明你的 DAL，在我看来这些都同样重要。
有几点需要考虑：
- 每次测试时，您的数据库都需要处于已知状态。大多数系统为此使用备份或创建脚本。
- 每个测试都必须是可重复的
- 每个测试都必须是原子的
设置数据库有两种主要方法，第一种是运行 UnitTest 创建数据库脚本。这可确保您的单元测试数据库在每次测试开始时始终处于相同状态（您可以重置它或在事务中运行每个测试以确保这一点）。
您的另一个选择是我所做的，为每个单独的测试运行特定的设置。我认为这是最好的方法，主要有两个原因：
- 您的数据库更简单，每个测试都不需要完整的架构
- 每个测试都更安全，如果您在创建脚本中更改一个值，它不会使其他几十个测试无效。
不幸的是，您在这里的妥协是速度。运行所有这些测试、运行所有这些设置/拆卸脚本都需要时间。
最后一点，编写如此大量的 SQL 来测试您的 ORM 可能非常困难。这是我采取非常讨厌的方法的地方（这里的纯粹主义者会不同意我的观点）。我使用我的 ORM 来创建我的测试！我没有为系统中的每个 DAL 测试使用单独的脚本，而是有一个测试设置阶段，它创建对象、将它们附加到上下文并保存它们。然后我运行我的测试。
这远非理想的解决方案，但在实践中我发现它更容易管理（尤其是当您有数千个测试时），否则您会创建大量脚本。实用胜于纯洁。
毫无疑问，我会在几年（几个月/几天）后回顾这个答案，并且随着我的方法发生变化，我不同意自己的看法 - 但这是我目前的方法。
为了尝试总结我上面所说的一切，这是我的典型数据库集成测试：
[Test]
public void LoadUser()
{
this.RunTest(session => // the NH/EF session to attach the objects to
{
var user = new UserAccount("Mr", "Joe", "Bloggs");
session.Save(user);
return user.UserID;
}, id => // the ID of the entity we need to load
{
var user = LoadMyUser(id); // load the entity
Assert.AreEqual("Mr", user.Title); // test your properties
Assert.AreEqual("Joe", user.Firstname);
Assert.AreEqual("Bloggs", user.Lastname);
}
}
这里要注意的关键是两个循环的会话是完全独立的。在您的 RunTest 实现中，您必须确保上下文已提交和销毁，并且您的数据只能来自您的第二部分的数据库。
2014 年 13 月 10 日编辑
我确实说过我可能会在接下来的几个月中修改这个模型。虽然我在很大程度上支持我上面提倡的方法，但我稍微更新了我的测试机制。我现在倾向于在 TestSetup 和 TestTearDown 中创建实体。
[SetUp]
public void Setup()
{
this.SetupTest(session => // the NH/EF session to attach the objects to
{
var user = new UserAccount("Mr", "Joe", "Bloggs");
session.Save(user);
this.UserID = user.UserID;
});
}
[TearDown]
public void TearDown()
{
this.TearDownDatabase();
}
然后分别测试每个属性
[Test]
public void TestTitle()
{
var user = LoadMyUser(this.UserID); // load the entity
Assert.AreEqual("Mr", user.Title);
}
[Test]
public void TestFirstname()
{
var user = LoadMyUser(this.UserID);
Assert.AreEqual("Joe", user.Firstname);
}
[Test]
public void TestLastname()
{
var user = LoadMyUser(this.UserID);
Assert.AreEqual("Bloggs", user.Lastname);
}
这种方法有几个原因：
- 没有额外的数据库调用（一次设置，一次拆卸）
- 测试更加精细，每个测试验证一个属性
- Setup/TearDown 逻辑已从测试方法本身中移除
我觉得这让测试类更简单，测试更细化 (single asserts are good)
2015 年 5 月 3 日编辑
此方法的另一个修订版。虽然类级别设置对于加载属性等测试非常有帮助，但它们在需要不同设置的情况下用处不大。在这种情况下，为每个案例设置一个新类是多余的。
为了解决这个问题，我现在倾向于有两个基类SetupPerTest 和SingleSetup。这两个类根据需要公开框架。
在SingleSetup 中，我们有一个与我第一次编辑中描述的非常相似的机制。一个例子是
public TestProperties : SingleSetup
{
public int UserID {get;set;}
public override DoSetup(ISession session)
{
var user = new User("Joe", "Bloggs");
session.Save(user);
this.UserID = user.UserID;
}
[Test]
public void TestLastname()
{
var user = LoadMyUser(this.UserID); // load the entity
Assert.AreEqual("Bloggs", user.Lastname);
}
[Test]
public void TestFirstname()
{
var user = LoadMyUser(this.UserID);
Assert.AreEqual("Joe", user.Firstname);
}
}
但是，确保只加载正确实体的引用可以使用 SetupPerTest 方法
public TestProperties : SetupPerTest
{
[Test]
public void EnsureCorrectReferenceIsLoaded()
{
int friendID = 0;
this.RunTest(session =>
{
var user = CreateUserWithFriend();
session.Save(user);
friendID = user.Friends.Single().FriendID;
} () =>
{
var user = GetUser();
Assert.AreEqual(friendID, user.Friends.Single().FriendID);
});
}
[Test]
public void EnsureOnlyCorrectFriendsAreLoaded()
{
int userID = 0;
this.RunTest(session =>
{
var user = CreateUserWithFriends(2);
var user2 = CreateUserWithFriends(5);
session.Save(user);
session.Save(user2);
userID = user.UserID;
} () =>
{
var user = GetUser(userID);
Assert.AreEqual(2, user.Friends.Count());
});
}
}
总而言之，这两种方法都取决于您要测试的内容。