我们在当前项目中使用了Specflow和WatIn进行验收测试。客户希望我们使用Microsoft编码的ui。我从来没有测试过编码的ui，但是到目前为止我看到它看起来很麻烦。我想在我有一个ui之前预先指定我的验收测试，而不是由于一些记录/回放的东西。无论如何，有人可以告诉我为什么我们应该扔掉Specflow / watin组合并用编码的ui替换它？
我还读到你可以将specflow与编码的ui结合起来，但是对于我在specflow中已经做得很好的事情看起来很多开销。
答案 0 :(得分：10)
我写了一篇关于如何做到这一点你可能会觉得有用的博客文章
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
我能想到的Coded UI Test的专业版和版本是您正确测试应用程序用户将如何使用它。这对于验收测试很有用，但它也有其局限性。它也非常适合端到端测试。在过去，UI测试已被证明是脆弱的。例如，当MS创建VS2010 UI时，几乎所有的UI测试都破了。主要原因是技术变革。编码的UI测试确实有助于通过匹配控件的方式来限制这种情况。它使用更多基于概率的匹配。这意味着它将尝试根据其拥有的信息（例如控件名称）找到最佳匹配。对我们来说，由于技术限制，我们选择了编码UI测试。我们的Legacy应用程序是VB，虽然CUIT不能很好地工作，但我正在编写扩展以获得更好的控制信息，它仍然是我们唯一的选择。另外请记住，CUIT是新的，有其自身的局限性。您应该准备好按照布局项目的方式进行结构化，因为VS2010中当前的端到端行为可以保持您的UIMap可以进行一些手动操作，例如从现有的操作记录创建CUIT总是放置UIMap中的测试称为UIMap.uitest，无法更改或转移到另一个UIMap。如果您使用多个ui地图，这意味着您需要先记录您的步骤，然后在测试中使用它们。然而，在.net中，它仍然非常灵活。
到目前为止，关于specflow的最好的事情是它的gerkin语法的可读性和生活文档。通常，您的应用程序的测试功能或行为是值得的地方。它通常将测试目标定位在UI下方。当UI在这里发生变化时，测试破坏的可能性会小一些。当您的应用程序不断变化并且您希望确保现有功能仍然有效时，我的规格很棒。它非常适合Scrum环境，您可以将其编写为关于它应如何工作的描述。我可以看到specflow的一个限制是它可以解释。因此，编写一个不可重用且难以维护的测试很容易。我喜欢使用更通用的术语来描述我的步骤，如“以User1登录”而不是“转到登录页面，输入用户名和密码，单击登录”。更细粒度地描述它使得重新使用它更难以将其耦合到UI。登录实际上如何工作应该取决于后面的代码而不是specflow功能。
然而，将2与我们结合起来似乎比仅使用编码的UI测试更有益。如果我们决定完全更改UI，我们至少会以任何人都能理解的方式将预期的行为存储在我们的specflow功能中。最后，您需要考虑应用程序的演变方式和应用程序类型。