我没有进行过多次单元测试（从未进行过TDD），但是我正在开发一个项目，我至少希望业务层可以进行单元测试，并且我可以做一些事情。似乎明白了。
说我有一个功能：
我认为我设法在这里正确地分离了业务，数据和表示问题：表单只包含与表示相关的代码，数据操作是在DAL（Linq to SQL）上进行的方法调用以及所有内容在业务逻辑层中进行协调。依赖关系注入构造函数;例如，表单需要DataTable，而不是Excel工作簿文件名。
如果我想到我可以（或者应该）写的测试，我......根本无法想到除了琐碎的（无用的？）那些验证a {{1循环执行预期的迭代次数，Foreach函数实际上确实将英寸转换为毫米（例如，测试GetMilimeterDimensions确实返回GetMilimeterDimensions(new SizeF(1f,1f))。现在好了读它看起来像函数的名称应该类似于 ConvertInchToMilimeter ，而且，这感觉就像一个函数，它属于某些 BusinessMath 类的静态方法。我猜错了例子。
重点是，我想要测试的所有这些函数和方法都是SizeF { Width = 25.4, Height = 25.4 }，最终由类'COM-visible private方法调用。这是否意味着我必须将它们Execute() 仅用于测试？或者，将我的功能的行为嵌入到一些公开其方法的 FunctionalityImplementation 类中，并让我的功能调用这些方法呢？感觉像是矫枉过正......
然后是DAL电话;我需要实现一些存储库模式以模拟CRUD操作，并能够编写验证是否插入预期数量的记录的测试......但这超出了我猜测的业务层可测试性。
尽管如此，似乎只是为了在一些VS插件中获得一堆绿点。我意识到，一旦编写了测试，代码更改就会破坏测试，这让你感谢测试是在第一时间编写的，但我认为我完全忽略了单元测试的重点，而且我写的测试将毫无意义一切都很有用;请在这里帮助我，我想的越多，我认为单元测试就越是强加其设计模式的额外工作。
不要误会我的意思（我想问题的标题），我确实看到了TDD的好处，我已经阅读了由单元测试爱好者编写的ASP.NET MVC书籍，但我似乎无法包装我将围绕如何将这些原则应用于一个简单的功能，更不用说整个COM可见的库项目......
答案 0 :(得分：2)
单元测试不是负担;它可以节省大量时间，防止错误，并促进重构，使代码保持可维护性和可塑性。
但是你可能不需要为这个项目进行单元测试。
最紧急的单元测试将确保您的业务逻辑能够按照您的想法执行。这在业务逻辑复杂，具有大量移动部件并且随着时间的推移可能会变得更加复杂的情况下非常有用：
Person *p = ...sample person....;
LoanRequest loan(p, $1,000,000);
Assert(loan.CanBeApproved(bankPolicy,region,market,term),true);
但如果基础逻辑简单且明显正确，那么它并不重要
Price=Total+Shipping;
同样，如果您正在编写快速小部件以便立即短期使用，则长期维护不是您首先关注的问题，而测试作为未来协作者文档的作用可能无关紧要。但是，如果您正在构建产品，那么您将需要这些测试。
一般而言，单元测试应主要关注公共行为。但偶尔您可能会发现验证通常是私有的中间结果要容易得多。将方法公之于众，或提供一个特殊的测试钩子，可以是一个合理的价格来支付软件按照你的想法做出的信心，并且即使在其他人开始改变它之后也会继续做你想的。