2

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

真正的事情是，我正在努力弄清楚如何对 UI 和更一般的生成事件的对象进行单元测试：用户控件、异步数据库操作等。

我的很多代码都与 UI 事件有关，以至于我什至看不到如何开始单元测试。

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

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

4

4 回答 4

2

要记住的是，单元测试是关于测试你编写的代码单元。您的单元测试不应该测试单击按钮会引发事件，而是测试由该单击事件执行的代码是否按预期执行。

您真正想要做的是测试底层代码是否能做它应该做的事情，以便您的 UI 层可以自信地执行该代码。

于 2008-09-01T12:19:14.367 回答
1

如果您在 UI 测试方面遇到困难，请 阅读本文

手动测试 UI 的东西，自动化它的成本效益是最小的。无情地测试 UI 皮肤下的一切。使用 Humble Dialog、MVC 或变体来保持逻辑和 UI 的独特性和松散耦合。

于 2008-09-01T13:13:57.307 回答
0

您应该将逻辑和表示分开。使用 MVP(Model-View-Presenter)/MVC (Model-View-Controller) 模式，您可以在不依赖 UI 事件的情况下对逻辑进行单元测试。您也可以使用White 框架来模拟用户输入。我强烈推荐你访问微软的Patterns&Practices 开发者中心，特别是看看复合应用程序块和 Prism——你可以获得很多关于测试驱动设计的信息。

于 2008-09-01T12:15:04.970 回答
0

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

测试事件并非不可能。例如，您可以为事件订阅一个匿名方法，如果事件被抛出或计算事件被抛出的次数，则该事件会抛出异常。

于 2008-09-01T12:18:02.387 回答