-3

我没有做过太多的单元测试（从来没有做过 TDD），但我正在做一个项目，我希望至少业务层是可单元测试的，而且有几件事我似乎无法做到理解。

假设我有一个功能：

  • 提示用户输入 Excel 工作簿文件名
  • 将工作簿的内容加载到网格中
  • 在表单上向用户显示该网格，该表单还接受用户的几个输入
  • 显示带有进度条的模态表单，该进度条在功能异步更新时...
    • 执行这样或这样的操作（基于现在关闭的表单上的用户输入）并且 - 粗略地说，最终将网格内容导入数据库表。

我想我在这里设法正确分离了业务、数据和表示关注点：表单仅包含与表示相关的代码，数据操作是在 DAL（Linq to SQL）上进行的方法调用，一切都在业务逻辑层进行协调。依赖注入到构造函数中；例如，表单需要一个DataTable，而不是 Excel 工作簿文件名。

如果我想到我可以（或应该）编写的测试，我......除了验证Foreach循环执行预期迭代次数的琐碎（无用的？）测试之外，我想不出任何测试，GetMilimeterDimensions函数确实做到了将英寸转换为毫米（例如，GetMilimeterDimensions(new SizeF(1f,1f))确实返回 a 的测试SizeF { Width = 25.4, Height = 25.4 }。好吧，现在阅读此内容，似乎函数的名称应该更像ConvertInchToMilimeter之类的东西，而且，这感觉就像一个属于某个BusinessMath类的静态方法的函数。不好我猜的例子。

重点是，我想要测试的所有这些函数和方法private，最终都由类的 COM 可见Execute()方法调用。这是否意味着我必须制作它们public 只是为了测试？或者，什么，将我的功能的行为嵌入到某些公开其方法的FunctionalityImplementation类中，并让我的功能调用这些方法？感觉有点矫枉过正...

然后是 DAL 调用；我需要实现一些存储库模式来模拟 CRUD 操作并能够编写测试来验证是否插入了预期的记录数量......但这超出了我猜的业务层可测试性。

尽管如此，似乎需要做很多工作才能在一些 VS 插件中获得一堆绿点。我意识到一旦编写了测试，破坏测试的代码更改会让你感谢测试是首先编写的，但我认为我完全错过了单元测试的重点，如果我写的测试将毫无意义完全有用；请在这里帮助我，我想得越多，在我看来，单元测试只是强加其设计模式的额外工作。

不要误解我的意思（我猜是问题的标题），我确实看到了 TDD 的好处，我读过单元测试爱好者写的 ASP.NET MVC 书籍，但我似乎无法理解如何将这些原则应用于一个简单的功能，更不用说应用于整个 COM 可见的库项目......

4

1 回答 1

2

单元测试不是负担；它可以节省大量时间、防止错误并促进重构，从而保持代码的可维护性和可塑性。

但是你可能不需要这个项目的单元测试。

最紧迫的单元测试将确保您的业务逻辑按照您的想法执行。这在业务逻辑很复杂、有很多移动部件并且随着时间的推移可能会变得更加复杂的情况下非常有用：

 Person *p = ...sample person....;
 LoanRequest loan(p, $1,000,000);
 Assert(loan.CanBeApproved(bankPolicy,region,market,term),true);

但是，如果底层逻辑简单且明显正确，这并不重要

 Price=Total+Shipping;

同样，如果您正在编写一个快速的小部件以立即短期使用，那么长期维护不是您首先关心的问题，并且测试作为未来合作者的文档的作用可能是无关紧要的。但是，如果您正在构建产品，您将需要这些测试。

一般来说，单元测试应该主要关注公共行为。但有时您可能会发现验证通常是私有的中间结果要容易得多。公开一个方法，或者提供一个特殊的测试钩子，可能是一个合理的代价，可以让你相信软件会按照你的想法去做，并且即使在其他人开始改变它之后也会继续按照你的想法去做。

于 2013-03-20T18:17:44.200 回答