Why should we use coded ui when we have Specflow?

Question

We used Specflow and WatIn for acceptance testing in my current project. The client wants us to use Microsoft coded-ui. I have never tested encoded ui, but from what I have seen so far, it looks bulky. I want to specify my acceptance tests first, before I have ui, and not as a result of some recordings / playbacks. Anyway, can someone please tell me why we should throw away the Specflow / watin combo and replace it with an encoded ui?

I also read that you can combine specflow with encoded ui, but that looks like a lot of overhead for something that I already do well in specflow.

Answer 1

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

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

The pro and the coded user interface argument that I can think of is testing the application exactly how the user will use it. This is good for acceptance testing, but it also has its limitations. It is also very good for testing the end. In the past, UI tests were known as fragile. For example, when MS created the VS2010 user interface, almost all UI tests broke. The main reason is technology change. UI coded tests help limit this because it matches the control. It uses more probability based on matching. This means that he will try to find the best match based on the information he has, for example, the name of the department. For us, Coded UI tests were our choice due to technology limitations. Our Legacy application is VB, and although CUIT does not work perfectly, I continue to write the extension to get better control information, but that was our only choice. Also keep in mind that CUIT is new and has its limitations. You need to be prepared to be very structured in how you plan your project, since saving your UIMaps may be a little manual due to the current end-to-end behavior in VS2010, for example, creating a CUIT from an existing action record is always a test in UIMap called UIMap.uitest, and there is no way to change this or pass it to another UIMap. If you use multiple ui cards, this means that you need to write down your steps first and then use them in your test. However, being in .net, it is still very flexible.

By far, the best thing about specflow is the gerkin syntax for readability and documentation. Typically, your test functions or the behavior of your application in which this value takes place is usually aimed at testing just below the user interface. There is a slightly less chance of breaking the test when the user interface changes here, but there. The spectrometer works fine for me when your application is under constant change and you want existing functions to remain functional. It fits well with the Scrum environment, where you can write your script as a description of how it should work. One limitation on specflow that I see is open to interpretation. Because of this, it can be easy to write a test that is not very reusable and difficult to maintain. I like to use more general terms to describe my steps, such as “Log in as User1” rather than “Go to the login page, enter your username and password, click“ Log in. ”Describing it more granular, it complicates the reuse of it in pairs interface How the login actually works, it depends on the code that is not associated with the specflow function.

Combination 2, however, seems more useful to us than just using coded user interfaces. If we decide to completely change the user interface, we will at least have behavior that is expected to be stored in our specflow functions in a way that anyone can understand. In the end, you need to think about how the application will develop and the type of application.