我很长一段时间以来一直是.Net开发人员，我正试图围绕真实，实用的单元测试。
最具体地说，我正在研究ASP.Net MVC 3项目的单元测试。
我已经读了很多关于它的信息，并且相信我在学术层面上理解它（即基本上确保你所做的改变不会破坏其他东西）。但是，我在例子中看到的所有测试都是非常愚蠢的事情，无论如何都会是一个非常明显的问题（这个控制器是否会返回一个具有此名称的视图？）。
所以，也许我错过了一些东西，或者只是没有看到任何真正好的测试例子或东西，但它看起来像是一堆额外的工作和复杂的嘲弄，ioc等我只是没有看到反平衡的收益。
请教我：）
答案 0 :(得分：0)
如果进行适当的单位测试，那么抓住原本会滑过你的角落几乎是微不足道的。假设您有一个返回项目列表的方法，并从某个表中检索项目列表。如果该表未正确填充（例如，如果其中一个列中有空值或为空）或者如果他们将列类型更改为您的ORM工具未按您认为的那样映射的内容，会发生什么？单元测试有助于在您投入生产之前捕获这些案例，并且有人会删除表中的所有数据。
答案 1 :(得分：0)
基本上可以确保您所做的更改不会破坏其他内容
这不是单元测试，而是regression testing。 Unit testing用于单独测试最小的代码片段（通常在类级别）。这在项目很小或没有类的情况下不是很有用。
在许多情况下，某些形式的单元测试（通常与其他形式混合，我喜欢使用mock testing，如果我有时间），非常有用。假设您有一个包含大约20多个类的大型项目，并且您在其中一个类中遇到错误。您可能需要深入了解每个类，并确保其方法返回正确的信息。这是单元测试。
简而言之，当您需要测试特定类或特定方法以确保它们正常运行时，将使用单元测试。当您使用最小的单元时，通过程序找到问题要容易得多，而不是通过整个程序来找出哪种方法不能正常工作