单元测试要走多远

之前曾多次问过一个问题，但twds mvc开发有特定的倾向。

我一直是一个非常好的男孩，并且一直用相应的单元测试来编码我的所有控制器动作，这非常好（如果有时[读很多]重复的话）。老实说，我实际上已经创建了一个T4模板来编写初始单元测试的大部分裸露的骨骼，然后根据使用情况进行适当的调整。我承认我不太确定如何在包含局部视图的视图中处理测试-但这是另一个问题。

现在，我难以决定的部分就是服务层应该覆盖的深度。原因是我的某些服务方法（无论好坏）实际上执行各种linq查询，然后将谨慎的信息提供给方法中的后续逻辑。我知道我可以（应该？？）分解这些方法，以便仅为每个linq语句调用所需的逻辑，然后将其应用到该方法中。但是，在许多情况下，永远不会重复使用linq'functions'，因此感觉这会将代码重构的程度过高。

我要问的是，在方法中发生复杂的逻辑时，是否有一种“足够好”的测试方法来简单地声明所需的结果和/或预期的错误，或者是否应该同时模拟和测试每条逻辑线。按照我的观察方式，正确进行测试，然后方法逻辑（逐行）也应具有某种覆盖率。但是（以我的幼稚观点），这可能导致试图保持测试和所实施的方法如此紧密一致（我知道他们应该如此）以至于在测试本身中创建家庭行业的循环永无止境。

我知道我的问题可能会激怒TDD的一些奉献者，他们会认为这是毫无道理的。不在TDD阵营中，这对我来说是“是明智的选择”，因此是一个问题。

顺便说一句-检查了这个想法：

http://dotnetslackers.com/articles/aspnet/Built-in-Unit-Test-for-ASP-NET-MVC-3-in-Visual-Studio-2010-Part-1.aspx

现在展望稳步下降:)

[编辑] -为单身人士（现在是单身！）的“亲密”选民提供好处。这个问题不是主观的。我正在寻找一个非常集中的主题的共识。我不是想激起负面的热情，我不是要揭露技术的缺陷-我是一个巨大的粉丝。因此，请在投票结束时发表有礼貌的评论，以使我受益，因为如果有歧义或错误信息，这可能有助于我重新构造问题。这个问题可能会使大部分的mvc受益。

谢谢！！

吉姆

首先，您所谈论的听起来并不像TDD。TDD表示一种测试优先的方法，该方法通过遵循Test-> Code-> Refactor的模式来驱动系统的设计 。因此，也许您的第一个问题是测试的目的，是在编写代码时编写它们吗？如果是这样，我希望测试中的几乎所有逻辑都与某个单元测试有关。因此，高代码覆盖率是应用TDD的间接结果。

在执行TDD时，您编写了足够的测试代码来激发您要编写的代码。您还应确保测试首先失败。基本上问自己，这种方法需要做什么。然后，您对其进行编码，但足以使测试通过，如果不是您要寻找的内容，则编写其他测试，然后重构该方法。

尽管您通常会发现使用TDD编写的代码中的代码覆盖率非常高，这是因为事实证明所有代码都应该受到某种测试的激励，但是事实之后的代码覆盖率并不是衡量您对TDD遵从性的有效方法。

TDD测试不仅可以驱动设计和文档，还可以用通俗易懂的语言向他人解释设计（因此，如何命名测试非常重要）。

但是，这些杂乱无章确实不能直接回答您的问题，所以我只想说，您应该针对相当高的服务（非UI）代码覆盖率，尤其是在存在非常规逻辑的地方，并且如果测试是更好的话首先写;-)。事实是（尽管有些人可能会不同意），通常更多的测试会更好。许多高质量的开源项目具有比运行代码更多的测试代码。

此外，应在以下情况下编写测试：

1. 您正在编写新代码，测试应驱动并记录您的设计，并解释您对代码应做的假设。应当在编写代码之前编写。

2. 您发现了一个错误，测试失败会证明该错误。修正错误后，测试即会通过。

3. 您以改变方法或类的性质的方式更改代码（尽管如果在代码的一个区域更改时很多测试失败，则可能表明测试很脆弱）。这样可以使测试正确地记录代码。

就个人而言，我发现学习TDD是一项有趣的挑战，并且需要时间来培养良好的“直觉”。练习，练习，练习一直是我学习的最好方法。那并从开放源代码项目中读取测试代码，现在还用我所做的更改编写新测试时为它们做出了贡献。

显然，仅测试方法的返回值不如测试方法中的所有分支。不能保证备用输入的正确行为。

另一方面，您可能没有足够的时间或耐心来测试所有内容。

您可以做的是确定要覆盖测试的代码量（80％到90％或其他），并使用自动工具对此进行验证。
仅当代码编写周期也永无止境时，才会发生编写测试的“永无止境的周期” :)

您想确定自己的代码正常运行吗？单元测试只是程序员囊中的一种工具，可以帮助验证您的实现是否满足规范要求。您可能不需要100％的覆盖率，但是您应该编写单元测试以覆盖代码中更关键的部分。确保您的方法可以很好地协同工作，而不仅仅是单独使用，这总是很好的，因此，您应该尝试编写一些测试来涵盖一些更关键的“逻辑行”。

在Visual Studio中打开代码覆盖率的情况下运行单元测试，应该可以很好地（图形化）指示代码覆盖率。

如果您不使用内置的MSTest框架，则可能需要查看第三方代码覆盖产品以与NUnit配合使用，或按照此处的说明进行操作：https : //stackoverflow.com/questions/2665799/does-vs2010-code -coverage-support-nunit