所以我知道单元测试是必须的。我认为 TDD 是添加新模块时要走的路。即使，在实践中，我实际上并没有这样做。真的有点像注释代码。
真正的问题是，我正在努力弄清楚如何对 UI 和更一般的生成事件的对象进行单元测试：用户控件、异步数据库操作等。
我的很多代码都与 UI 事件相关，以至于我什至不知道如何开始单元测试。
那里一定有一些入门和入门文档吗？一些提示和技巧？
我通常使用 C#（2.0 和 3.5）工作，但我不确定这与问题是否严格相关。
【问题讨论】：
标签： visual-studio unit-testing user-interface tdd
您应该将逻辑和表示分开。使用 MVP(Model-View-Presenter)/MVC (Model-View-Controller) 模式，您可以在不依赖 UI 事件的情况下对您的逻辑进行单元测试。 您也可以使用White framework 来模拟用户输入。 我强烈建议你访问微软的Patterns&Practices developer center，尤其是看看复合应用程序块和棱镜——你可以得到很多关于测试驱动设计的信息。
【讨论】：
应用程序中与外界通信的部分（即 UI、数据库等）在进行单元测试时总是会出现问题。解决这个问题的方法实际上不是测试这些层，而是让它们尽可能薄。对于 UI，您可以使用不起眼的对话框或不做任何值得测试的视图，然后将所有逻辑放在控制器或演示器类中。然后，您可以使用模拟框架或编写自己的模拟对象来制作视图的假版本，以测试演示者或控制器中的逻辑。在数据库方面，您可以执行类似的操作。
测试事件并非不可能。例如，您可以为事件订阅一个匿名方法，如果事件被抛出或计算事件被抛出的次数，则该事件会抛出异常。
【讨论】：
要记住的是，单元测试是关于测试您编写的代码单元。您的单元测试不应该测试单击按钮会引发事件，而是测试由该单击事件执行的代码是否按预期执行。
您真正想要做的是测试底层代码的功能，以便您的 UI 层可以放心地执行该代码。
【讨论】：
Read this 如果您正在为 UI 测试而苦苦挣扎
手动测试 UI 的东西，自动化它的成本收益是最小的。无情地测试 UI 皮肤下的一切。使用 Humble Dialog、MVC 或变体来保持逻辑和 UI 的独特性和松散耦合。
【讨论】：