作为TDD的初学者，我尝试编写一个测试，假定属性在PropertyGrid(C＃，WinForms，.NET 3.5)上更改了其值。

更改属性网格中对象的属性不会触发该事件(这很公平，因为它是UI引发的事件，所以我可以看到为什么更改拥有的对象对其不可见)。

在更改SelectedNode属性时，在TreeView上触发AfterSelect也会遇到同样的问题。

我可以有一个单元测试可以调用的函数，该函数可以模拟UI事件触发的代码，但这会使我的代码混乱不堪，除非我将其公开，否则我必须将所有测试写在同一个项目中，甚至是我正在测试的对象的类(再次，我认为这很混乱)。在我看来，这很丑陋，并且会遇到可维护性问题。

是否有约定进行此类基于UI的单元测试

解决方案

我推荐的一个简单选择是让UI在事件触发时调用帮助程序类或者方法，并对该单元进行测试。确保它(UI中的事件处理程序)具有尽可能少的逻辑，然后从那里确定我们将要做什么。

在单元测试中很难达到100％的覆盖率。当然，我很难说的是效率低下。我认为，即使我们擅长于这种事情，它也可能会给代码库增加比单元测试值得的复杂性。如果我们不确定如何将逻辑划分为单独的类或者方法，这是我想帮助的另一个问题。

我将很感兴趣地了解人们必须使用哪些其他技术来解决此类问题。

Microsoft在.Net Framework中内置了UI自动化。我们可能可以使用它来模拟用户以正常方式使用软件。

有MSDN文章"使用UI自动化进行自动测试，这是一个很好的起点。

要对代码进行单元测试，我们将需要模拟UI界面元素的对象。我们可以使用许多工具来执行此操作，因此我不推荐我们使用一种工具。 Moha和Rhino Mocks在Phil Haack的博客上有一个很好的比较，我发现它很有用，可能对我们有用。

如果我们正在使用TDD，则要考虑的另一件事是创建视图的接口，这将有助于TDD流程。为此有一个设计模型(可能不止一个，但我使用的是一个)，称为模型视图演示器(现在分为被动视图和主管控制器)。遵循这些规则之一将使我们后面的代码将来更可测试。

另外，请记住，不能通过单元测试来测试UI本身。另一个答案中已经建议的测试自动化工具将适用于此，但不适用于代码的单元测试。