拥有Specflow时为什么要使用编码的ui？ [英] Why should we use coded ui when we have Specflow?

问题描述

在我当前的项目中，我们已经利用Specflow和WatIn进行了验收测试。客户希望我们改用Microsoft编码的ui。我从未测试过ui编码，但到目前为止，它看起来很麻烦。我想在拥有ui之前预先指定我的验收测试，而不是由于某些记录/播放的结果。无论如何，有人可以告诉我为什么我们应该扔掉Specflow / watin组合并用编码的ui代替吗？

We have utilized Specflow and WatIn for acceptance tests at my current project. The customer wants us to use Microsoft coded-ui instead. I have never tested coded ui, but from what I've seen so far it looks cumbersome. I want to specify my acceptance tests up front, before I have a ui, not as a result of some record/playback stuff. Anyway, can someone please tell me why we should throw away the Specflow/watin combo and replace it with coded ui?

我还读到可以将specflow与编码的ui，但对于我在specflow中已经做得很好的事情来说，似乎有些开销。

I've also read that you can combine specflow with coded ui, but it looks like a lot of overhead for something which I am already doing fine in specflow.

推荐答案

我写了一篇有关如何执行此操作的博客文章

I wrote a blog post on how to do this you might find useful

http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests /

我能想到的编码UI测试的优缺点是您对应用程序的测试完全是用户的使用方式。这对验收测试很有好处，但也有其局限性。这对于端到端测试也非常有用。在过去，UI测试被认为是脆弱的。例如，当MS创建VS2010 UI时，几乎所有UI测试都失败了。主要原因是技术变化。编码的UI测试确实有助于通过与控件匹配的方式来限制这种情况的发生。它使用更多基于概率的匹配。这意味着它将尝试根据其具有的信息（如控件名称）找到最佳匹配。对我们而言，由于技术限制，我们选择了编码UI测试。我们的旧版应用是VB，尽管CUIT效果不佳，但我正在编写扩展程序以获取更好的控制信息，但这仍然是我们唯一的选择。还请记住，CUIT是新的并且有其自身的局限性。您应该准备好布局项目的结构，因为由于VS2010中当前的端到端行为，维护UIMap可能需要一些人工工作，例如，从现有动作记录创建CUIT总是放在在名为UIMap.uitest的UIMap中进行测试，无法更改它或将其转移到另一个UIMap。如果使用多个ui映射，则意味着您需要先记录您的步骤，然后在测试中使用它们。但是，在.net中它仍然非常灵活。

The pro's and con's of Coded UI Test that i can think of is your testing the application exactly how the user will be using it. This is good for acceptance test but it also has its limitations. Its also really good for end to end testing. In the past UI Tests have been know to be fragile. For example when MS created the VS2010 UI almost all of the UI tests broke. The main reason being is the technology change. Coded UI tests do help to limit this from happening by the way it matches a control. It uses more of a probability based match. This mean it will try to find the best match based on the information it has such as control name. For us Coded UI tests was our choice because of technology limitations. Our Legacy app is VB and although CUIT does not work great, i'm in the progress of writing an extension to get better control information, it was still our only choice. Also keep in mind CUIT is new and has its own limitations. You should be prepared to be very structured in the way you lay out your project as maintaining your UIMaps can be a bit of manual work due to the current end to end behaviour in VS2010, for example creating a CUIT from an existing action recording always places the test in a UIMap called UIMap.uitest and there is no way to change that or transfer to another UIMap. If you use multiple ui maps this means you will need to record your steps first and then use them in your test. However being in .net it its still very flexible.

到目前为止，specflow最好的地方是它的可读性和实时文档的gerkin语法。通常，您的应用程序的测试功能或行为就是价值的来源。它通常将测试放在UI下方。当用户界面在此处但在那里更改时，测试中断的机会要少得多。当您的应用程序不断变化并且您想确保现有功能仍在工作时，Specflow对我来说很棒。它也非常适合Scrum环境，您可以在其中编写方案的描述，以说明其工作方式。我可以看到，specflow的一个局限性是它可以解释。因此，编写不太可重用且难以维护的测试很容易。我想使用更通用的术语来描述我的步骤，例如以User1身份登录，而不是转到登录页面，输入用户名和密码，单击登录。将其描述得更细致使重用到UI变得更加困难。登录实际的工作方式应该取决于背后的代码而不是specflow功能。

By far the best thing about specflow is its gerkin syntax for readability and living documentation. Normally your testing features or behaviours of your app which is where the value comes from It generally aims the test just below the UI. There is a little less chance of the test breaking when the UI changes here but there. Specflow to me is great when your application is under constant change and you want to ensure existing features remain working. It fits well in a Scrum environment as well where you can write your scenario's as a description about how it should work. One limitation to specflow i can see is its open for interpretation. Because of this it can be easy to write a test that is not very reusable and hard to maintain. I like to use more generic terms to describe my steps like "Log in as User1" instead of "Go to Login Page, Enter Username and Password, Click login". Describing it more granular makes it harder to reuse tightly couples it to the UI. How the login actually work should be up to the code behind not the specflow feature.

但是，将2组合起来对我们来说似乎比仅使用编码UI测试更有利。如果我们决定完全更改UI，那么我们至少会以任何人都可以理解的方式将预期的行为存储在我们的specflow功能中。最后，您需要考虑应用程序将如何发展以及应用程序的类型。

Combining the 2 however to us seems more beneficial than just using Coded UI Tests. If we decide to completely change the UI we would at least have the behaviours that are expected stored in our specflow features in a way anyone can understand. In the end you need to consider how the application will evolve and the type of application.

这篇关于拥有Specflow时为什么要使用编码的ui？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！