我的应用程序中有一个数据访问层,它包装了一个 ADO.NET 数据提供程序。DAL 将数据提供程序返回的数据转换为 .NET 对象。我看过很多建议不要对 DAL 进行单元测试的帖子,但我担心那里可能会出错 - 有很多循环和强制转换以及空检查。
我对使用 RhinoMocks 之类的东西创建一个模拟 DbProvider 有一些想法,但是我必须在每个测试中模拟出的接口数量将是压倒性的,而且我必须设置的期望数量会使测试变得非常困难读书。似乎每个测试都会比它正在测试的代码更复杂——从单元测试的 3 个目标的角度来看,这将是一场灾难:
- 可读性
- 可维护性
- 可信度
我有一个想法来实现一个友好的 DbProviderFactory 来从 xml 加载示例数据。我可以在测试中通过依赖注入将其插入。它应该使维护测试变得更加简单。一个简单的例子可能是:
[TestCase]
public void CanGetCustomer()
{
var expectedCommand = new XmlCommand("sp_get_customer");
expectedCommand.ExpectExecuteDataReader(
resultSet: @"<customer firstName=""Joe"" lastName=""Blogs"" ... />");
var factory = new XmlProviderFactory(expectedCommand);
var dal = new CustomerDal(factory);
Customer customer = dal.GetCustomer();
Assert.IsNotNull(customer, "The customer should never be null");
Assert.AreEqual(
"Joe", customer.FirstName,
"The customer had an unexpected FirstName.");
}
我认为这种方法——使用友好的 DbProvider——可能会使测试 DAL 代码变得更容易。它将具有以下优点:
- 测试数据将在 xml 中,并且可以与单元测试一起放在源代码管理中。它可能在外部文件中,也可能在测试中。
- 我没有使用真正的数据库,所以这消除了状态问题。所以我不必在每次测试之前将数据库置于已知状态。
- 我不必在每个测试中模拟出所有的 ADO.NET 接口。我将编写一组可以在整个代码库中重复使用的假实现。
人们可以对这个想法提出一些批评吗?是否已经有类似的实现可以用于此?
谢谢