在我当前的项目中，我们使用 Specflow 和 WatIn 进行验收测试。客户希望我们改用 Microsoft coded-ui。我从未测试过编码的 ui，但从我目前看到的情况来看，它看起来很麻烦。我想在我有一个 ui 之前预先指定我的验收测试，而不是因为一些记录/播放的东西。无论如何，有人能告诉我为什么我们应该扔掉 Specflow/watin 组合并用编码的 ui 替换它吗？
我还读到您可以将 specflow 与编码的 ui 结合起来，但对于我在 specflow 中已经做得很好的东西来说，这看起来像是很多开销。
我写了一篇关于如何做到这一点的博客文章，你可能会觉得有用
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
我能想到的编码 UI 测试的优点和缺点是您测试应用程序的确切用户将如何使用它。这对于验收测试很有用，但也有其局限性。它也非常适合端到端测试。在过去，UI 测试被认为是脆弱的。例如，当 MS 创建 VS2010 UI 时，几乎所有的 UI 测试都失败了。主要原因是技术变革。编码的 UI 测试确实有助于通过匹配控件的方式来限制这种情况的发生。它更多地使用基于概率的匹配。这意味着它将尝试根据其拥有的信息（例如控件名称）找到最佳匹配。由于技术限制，我们选择了 Coded UI 测试。我们的旧版应用程序是 VB，虽然 CUIT 不能很好地工作，但我' m 在编写扩展以获得更好的控制信息的过程中，它仍然是我们唯一的选择。还要记住 CUIT 是新的并且有其自身的局限性。您应该准备好在您布置项目的方式上非常有条理，因为维护您的 UIMaps 可能是一些手动工作，因为 VS2010 中当前的端到端行为，例如从现有的动作记录创建一个 CUIT 总是放置UIMap 中的测试称为 UIMap.uitest，无法更改或转移到另一个 UIMap。如果您使用多个 ui 地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在 .net 中它仍然非常灵活。您应该准备好在您布置项目的方式上非常有条理，因为维护您的 UIMaps 可能是一些手动工作，因为 VS2010 中当前的端到端行为，例如从现有的动作记录创建一个 CUIT 总是放置UIMap 中的测试称为 UIMap.uitest，无法更改或转移到另一个 UIMap。如果您使用多个 ui 地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在 .net 中它仍然非常灵活。您应该准备好在您布置项目的方式上非常有条理，因为维护您的 UIMaps 可能是一些手动工作，因为 VS2010 中当前的端到端行为，例如从现有的动作记录创建一个 CUIT 总是放置UIMap 中的测试称为 UIMap.uitest，无法更改或转移到另一个 UIMap。如果您使用多个 ui 地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在 .net 中它仍然非常灵活。如果您使用多个 ui 地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在 .net 中它仍然非常灵活。如果您使用多个 ui 地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在 .net 中它仍然非常灵活。
到目前为止，specflow 的最佳之处在于其 gerkin 语法的可读性和活文档。通常，您的应用程序的测试功能或行为是价值的来源 它通常针对 UI 下方的测试。当 UI 在这里但那里发生变化时，测试中断的可能性会小一些。当您的应用程序不断变化并且您希望确保现有功能保持工作时，Specflow 对我来说非常棒。它也非常适合 Scrum 环境，您可以在其中编写场景作为关于它应该如何工作的描述。我可以看到对 specflow 的一个限制是它可以解释。正因为如此，编写一个不太可重用且难以维护的测试是很容易的。我喜欢使用更通用的术语来描述我的步骤，例如“以 User1 身份登录”而不是“
然而，将两者结合起来对我们来说似乎比仅使用编码的 UI 测试更有益。如果我们决定彻底改变 UI，我们至少会将预期的行为以任何人都可以理解的方式存储在我们的 specflow 功能中。最后，您需要考虑应用程序将如何发展以及应用程序的类型。