我一直在使用 TDD 进行服务器端开发。我不确定将所有生产代码都包含在单元测试中的好处是否超过了花费 4 倍于重构所需时间的劣势。
但是当我在开发 UI 代码时，我根本无法应用 TDD。对于那里的所有原教旨主义者，TDD 的第一定律指出“在编写失败的单元测试之前，您不得编写生产代码”。但是，如果您正在开发 UI，这怎么可能呢？
（可以使用 Selenium 之类的验收测试框架，但这不算数，因为您不直接与源代码交互。）
那么，我可以告诉我的经理，由于新的 >90% 代码覆盖率政策，我无法编写用户界面代码吗？
如果您发现编写 TDD 会使您在重构上花费 4 倍以上的时间，那么您需要编写更好、更独立的测试，并真正让测试按预期驱动设计。当您在没有测试的情况下进行重构时，您还没有计算在调试器中花费的时间，更不用说其他人在您重构时引入的错误上花费了多少时间。
不管怎样，这里有一些关于 TDD 对 UI 开发意味着什么的好建议。这将转化为代码覆盖率的程度在很大程度上取决于 UI 框架。
绝对不要告诉你的经理你做不到，他可能会用能做的人代替你。
TDD 是关于孤立地测试方法。如果你想测试你的 UI，你是在做集成测试而不是单元测试。因此，如果您仔细分离应用程序中的关注点，您将能够成功地将 TDD 应用于任何类型的项目。
首先，即使是 Robert Martin 也遇到了 UI 测试挑战。
在对 UI 进行 TDD 时，您会编写尽可能接近动作的“行为契约”。理想情况下，这意味着单元测试。但是一些 UI 框架使这变得异常困难，要求您退后一步并使用集成或“验收”测试来捕获您期望 UI 的行为方式。
如果您不能使用单元测试，这不算数吗？这取决于您使用哪些规则来记分。“只计算单元测试”规则对于初学者来说是一个很好的规则，就像“不要拆分不定式”或“避免被动语态”一样。最终，您会了解该规则的边界在哪里。在一个播客中，Kent Beck 谈到了适当地使用单元测试和集成测试的组合（如果我没记错的话，补充说这不会打扰他）。
如果 TDD 是您的目标，您当然可以先编写 Selenium 测试，尽管这可能是一种缓慢的方式。我参与了几个项目，这些项目使用 Selenium RC 取得了很好的效果（也很痛苦，因为测试运行得如此缓慢）。
无论你的框架是什么，你都可以在谷歌上搜索来自那些经历过相同战斗的人的 TDD 技巧。
该策略听起来有点人为，但我同意 UI 需要功能测试用例而不是单元测试的答案。然而，我不同意先到先得的观点。我曾在这样一个环境中工作过，在这种环境中，必须在开发 UI 之前编写 UI 功能测试，并且发现它工作得非常好。当然，这假设您也预先进行了一些设计工作。只要测试用例作者和开发人员就设计达成一致，就可以在您开始编码之前编写测试用例；那么你的代码必须让所有的测试用例都通过。相同的基本原则，但它并没有完全遵守法律。
单元测试不适用于 UI 代码。功能测试用于测试 UI，但您不能先编写这些测试。您应该与您的经理确认 >90% 的代码覆盖率政策是否也涵盖 UI 代码。如果是这样，他可能应该认真重新考虑这一举动。
将业务逻辑从 UI 中分离出来，保证 UI 代码占总数的 10% 以下？关注点分离是 TDD 的主要目标，所以这实际上是一件好事。
就 90% 的覆盖率而言......好吧，最好的课程是回顾现存的文献（我会关注 Kent Beck 和 Bob Martin），我认为你会发现不遵循盲目覆盖率的支持（事实上，我想鲍勃叔叔最近写了一篇关于这个的博客文章）。
拥有 >90% 的代码覆盖率是愚蠢的，因为聪明的开发人员可以在一次测试中获得 100% 的覆盖率。;)
如果您使用的是 WPF，如果您使用 MVVM 模式，则可以测试您的 UI 代码。通过测试您的 UI 代码，我的意思是您可以测试 ModleView，但我知道没有任何东西可以测试 XAML。
阅读菲利普的书