Starting with Eyeshot 2020, we introduced a series of interactive tests to cover particular scenarios that cannot be tested with the standard unit testing approach. We tried some commercial solutions, but we found out that they were congenial for testing a full application, not a single and complex component like Eyeshot. We need something more flexible and customizable and in this article, we'd like to explain the thoughts behind our choices and how we achieved it.
The goal
The idea is to create several automated tests, using a common approach both for WinForms and WPF platforms, to have the possibility to perform the same test without code duplication for all the Eyeshot renderer cases (WPF, WinForms OGL,...).
What we need to achieve it
- A mechanism to interact with Eyeshot without external components like a button.
- A way to simulate the user interaction with the GUI.
- Standalone application based on Eyeshot to perform tests for all the workspaces (Design, Drawings, Simulation and Manufacture).
- A way to record user actions and create new tests quickly.
How we implement it
-
There is no common implementation for the UI Automation support both for WinForms and WPF platforms. So we implement different methods with similar behavior. In particular, the System.Windows.Forms.Control.CreateAccessibilityInstance() method for WinForms and the System.Windows.Automation.Peers.AutomationPeer.OnCreateAutomationPeer() method for WPF. Both of them give the opportunity to receive a string value as input and return a string value back. In this way, we can just use an enumerative to handle different actions for both platforms.
- To simulate the user interaction we choose the FlaUI open-source library. It's based on native UI Automation libraries from Microsoft and it supports both the above patterns.
- The below scheme summarizes the structure we use for our purpose.
There are two standalone apps (for WinForms and WPF platforms) based on a common library for the Eyeshot initialization. Another library contains a repository for loading geometry. And a third one contains the tests code. - Standalone applications integrate a custom action recorder that intercepts Eyeshot events and traduces them to a ready-to-use code for testing.
How it works
Each test simulates user interaction (e.g. mouse click), runs commands to Eyeshot (e.g. changes its action mode) and performs image comparison to check the current scene rendering.
As already written, the same test is performed for all the renderer types and both platforms.
Conclusion
Automating GUI testing can be very tricky and user behavior is complex. Consequently, it makes sense to use a ready-made GUI test automation tool like Ranorex or Telerik Test Studio for testing a full application. On the other hand, it's good to know you can create your own testing environment for a custom .NET component like Eyeshot.
Comments
Please sign in to leave a comment.