所以我知道单元测试是必须的。我认为添加新模块时TDD是必经之路。即使在实践中，我实际上并没有这样做。确实有点像注释代码。

真实的是，我正在努力使自己对如何对UI以及更一般的生成事件的对象进行单元测试：用户控件，异步数据库操作等。

我的大部分代码都与UI事件有关，以至于我什至不知道如何开始单元测试。

那里一定有一些入门和入门文档？一些提示和技巧？

我通常在C(2.0和3.5)中工作，但是我不确定这是否与问题严格相关。

解决方案

回答

我们应该将逻辑和表示法分开。使用MVP(模型视图呈现器)/ MVC(模型视图控制器)模式，我们可以对逻辑进行单元测试，而无需依赖UI事件。
我们也可以使用White框架来模拟用户输入。
我强烈建议我们访问Microsoft的Patterns＆Practices开发人员中心，尤其是查看复合应用程序块和Prism时，我们可以获得有关测试驱动设计的大量信息。

回答

当进行单元测试时，与外界对话的应用程序部分始终是一个问题。解决此问题的方法实际上不是测试这些层，而是使其尽可能薄。对于UI，我们可以使用不起眼的对话框或者不执行任何值得测试的视图，然后将所有逻辑放入控制器或者演示者类中。然后，我们可以使用模拟框架或者编写自己的模拟对象来制作视图的虚假版本，以测试演示者或者控制器中的逻辑。在数据库方面，我们可以执行类似的操作。

测试事件并非不可能。例如，我们可以为该事件订阅匿名方法，如果该事件被抛出，则该事件将引发异常，或者计算该事件被抛出的次数。

回答

要记住的是，单元测试就是测试我们编写的代码单元。单元测试不应测试单击按钮会引发事件，而是应由该单击事件执行的代码按预期运行。

我们真正想做的是测试基础代码是否应该执行应有的工作，以便UI层可以放心地执行该代码。

回答

如果我们在进行UI测试方面遇到困难，请阅读本文

手动测试UI东西，使其自动化成本最小化。认真测试UI皮肤下的所有内容。使用Humble Dialog，MVC或者变体来保持逻辑和UI的不同和松散耦合。