我知道在编写失败的单元测试之前,我可能不会编写生产代码,所以我可以告诉我的经理我不能编写UI吗?[关闭]

如果你发现编写TDD会使你在重构上花费4倍的时间,那么你需要编写更好、更独立的测试,并真正让测试按预期驱动设计。当你在没有测试的情况下进行重构时,你也没有计算在调试器中花费的时间,更不用说其他人在你重构时引入的bug上花费了多少时间了。

不管怎样, here

绝对不要告诉你的经理你做不到,他可能会用能做到的人来代替你。

首先,即使是罗伯特·马丁 testing challenges with UIs .

当TDDing一个UI时,你会编写尽可能接近动作的“行为契约”。理想情况下,这意味着单元测试。但一些UI框架使这变得异常困难,要求你退一步,使用集成或“验收”测试来捕捉你对UI行为的期望。

如果TDD是你的目标,你当然可以先编写Selenium测试,尽管这可能是一种缓慢的方法。我参与过几个项目,这些项目使用了Selenium RC,效果很好(也很痛苦,因为测试运行得很慢)。

无论你的框架是什么,你都可以在谷歌上搜索那些经历过同样战斗的人的TDD技巧。

TDD是关于独立测试方法的。如果你想测试你的UI,你正在做集成测试,而不是单元测试。因此,如果你仔细地将应用程序中的关注点分开,你将能够成功地将TDD应用于任何类型的项目。

单元测试不适合UI代码。功能测试用于测试UI,但您无法先编写这些测试。您应该咨询您的经理,看看是否>90%的代码覆盖率政策也涵盖了UI代码。如果真是这样,他可能应该认真重新考虑这一举措。

将业务逻辑与UI分离,并确保UI代码占总数的10%以下?关注点分离是TDD的主要目标,所以这实际上是一件好事。

A具有>90%的代码覆盖率是愚蠢的,因为一个聪明的开发人员可以在一次测试中获得100%的覆盖率。 ;)

如果你使用的是WPF,如果你使用MVVM模式,你可以测试你的UI代码。通过测试你的UI代码,我的意思是你可以测试ModleView,但据我所知,没有任何东西可以测试XAML。

阅读 Phlip's book