I am using UI Automation library - TestStack.White to automate a Windows Application, where I utilize Inspect.exe to get the UI Elements from the WinForms. I have had no issues with the Inspect.exe so far except currently I am stuck with an issue in my development machine where the tool started recognizing the "Buttons" as "Pane" and the behavior is same across Visual UIA Verify, TestStack(White). Eventually all the tests are getting failed since it couldn't identify the Buttons (returns Null).
Here's what it looks like now,
[]
Here's what it used to look and it looks in a Fresh VM,
Expected,
[]
Can someone please through some light regarding this behavior or point out what would have gone wrong here ?
Thanks in Advance !
Hmm... It looks like a bug in UIAutomationCore.dll or a target application issue. I think you can't do something with that on client side. But some workarounds are possible. It's still recognized as a class name with BUTTON inside. So it's possible to do some part of your automation with a tool that can support both UI Automation (for complicated controls like WinForms list views etc) and Win32 API (like here, when it has NativeWindowHandle and adequate ClassName).
If you can consider changing the automation tool, one of the options is pywinauto. It can use Win32 API or UI Automation under the hood by your choice. The high level API is almost the same. So you can easily switch between 2 backends for different actions (having 2 different Application objects connected to one target app instance). Getting Started Guide will bring you initial guidance for the core concept.
Related
I was a .net based windows application developer and being a web developer now.
For the last couple of years, I tried to follow principles of Specification by example in a project.
On the last project I was involved, our team used WPF with MVVM(Model-View-ViewModel) pattern and I tried SpecFlow for testing. (Well.. the coverage by SpecFlow was very low though cause it was not officially adopted from our team and I couldn't spend enough time on it.)
Now our team started to migrate the existing windows application to a web based application and decided to use cucumber.js as a tool for implementing 'Specification by example'.
When I was trying SpecFlow before, I made all the step definitions to test ViewModel layer instead of View and it was the only way actually. What I'm confused with cucumber.js is that most of examples demonstrate how to test features via web browsers(headless or real ones).
If the features are specifying specific ui behaviors then accessing a DOM element and evaluating its value make sense. However, as far as I learned about Specification by examples, testing under the UI layer is recommended instead of UI elements directly.
It seems like most of modern web applications have layers such as MVC, MVVM(knouckout.js) nowadays. Our web application will use Angularjs and this is my theory.
I guess it is possible to use feature files - which do not state any specific UI controls and behaviors - to test under the skin of UI layer, without relying browser support. That layer would be Model of angularjs, not ui elements.
Is this approach missing something or wrong with cucumber.js?
Please give me some insights and correct me if I'm wrong.
Thanks in advance!
Specification by example specifies requirements by giving examples from the point of view of the user. What's more representative of the user: clicking items on a web page, or directly calling code? A user won't be calling methods on your view model, so in my opinion a feature test is a much better way to test expected behaviour.
Recently I developed an application using a Pivot control as a "menu" and other pages with XNA content (2D and 3D).
Now, I discovered that my application won't be certified cause Im using System.XNA.Framework.Game and System.XNA.Framework.Graphics in my app.
This is really upsetting me at the moment, cause it's throwing away hours of work...
I never published something on the marketplace, so I'm asking if it's possible, anyway, to publish an application of this kind or at least, publish it as Beta Testing without "Certification" as they say on few pages..
Any clue?
Composite Silverlight+XNA applications are different from full-featured Silverlight applications invoking XNA assemblies. The restriction is still there - you must not have calls to Microsoft.Xna.Framework.Game or Microsoft.Xna.Framework.Graphics.
Mind you, some XNA elements are still allowed, such as Microsoft.Xna.Framework.Audio, that gives you access to the Microphone class, or Microsoft.Xna.Framework, that lets you access the FrameworkDispatcher.
My manager asked me to do some automated UI tests for our Silverlight application. The problem is that this application uses some custom controls, therefore I cannot programmatically access them right away.
The only way to access them is to use AutomationPeer, but my manager doesn't like this idea, because it goes against testing principle to change the code in order to support UI automation; the code should be tested as-is.
Is there a method or a tool that will enable me to create automated Silverlight UI tests, without the use of AutomationPeer?
Your custom controls should support automated testing, but that same mechanism is how accessibility tools interact with them.
Tell your manager, 'I need to add accessibility support, and automation comes free'.
In short, if you can't automate your control, a blind, deaf, and/or limited mobility person can't use it anyway.
There are several solutions. One is you can write full support via a UITestExtionsPackage Take a look at these
http://blogs.msdn.com/b/gautamg/archive/2010/03/23/writing-extension-for-wpf-custom-control.aspx
http://blogs.msdn.com/b/mathew_aniyan/archive/2011/05/17/custom-wpf-control-s-custom-properties.aspx
However this solution might be a simpler one
http://blog.benday.com/archive/2011/07/18/Silverlight-Coded-UI-Tests-with-UserControls-amp-AutomationProperties.aspx
I want to automate the application develoepd in silverlight. Can you let me know whether there are any open source tools are available which can be used for automating SilverLight app. Thanks.
We are doing UI testing on a Silverlight application using the UIAutomation API, and it works very nicely.
Project White is a library that sits on top of UIAutomation, and many people find it helpful. I prefer to use the UIAutomation APIs directly - it's really not as hard as you might think, as my tutorial shows.
If you're looking to perform User Interface Automation (UIA) to simulate mouse clicks, keyboard presses, etc. there is no "easy" way to get this today.
I've seen some third party tools that may work, such as Telerik's. Note that I have not used and do not endorse this, just know it is out there!
I am currently trying out Project White and finding it quite easy to use.
Before using Project White I tried out WiPFlash which was also rather easy to use. It just lacked a few features that I was after (Right Click and Drag options).
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.