Test automation of WPF-based application with TestComplete
January 20, 2022
Test automation of WPF-based application with TestComplete
Score 8 out of 10
Vetted Review
Verified User
Overall Satisfaction with TestComplete
We use TestComplete to automate testing of Microsoft Office AddIns that are based on .NET and WPF. We use a mix of keyword tests and scripting to create testing suites that can run autonomously and report through various checkpoints (region checkpoints for visuals, OCR checkpoints for text recognition, property checkpoints to verify the expected status of UI elements). The interfacing of scripts and keyword tests can be a hassle, but is still very doable and allows for different levels of expertise to work together. Objects can be found, identified (by their properties), and saved in the name mapping that also allows to then address them under an alias for improved usability. Finding objects is possible both by locating them on-screen or if they are in a lower hierarchy (or you'd like to add mappings for non-visual objects) the object browser is a powerful tool to analyze the whole structure of an application. This provides us with key functionality for our test automation.
- Identifying UI objects and application structure
- Expandability of tests through scripts and script extensions/plugins
- low barrier of entry (you can get started quickly, and other's don't need much explanation to contribute on a basic level)
- Possibility of Jira integration for reporting
- Relatively few (and usually easy to solve) git conflicts when working simultaneously
- easy handling of test data, also for iterative tests
- The documentation is lackluster in many areas and especially for scripting, script extensions, and plugins, there's a lot of copy/paste. Trying to grasp a specific aspect is often impossible in these areas and it feels like one would really have to read the documentation from start to finish to not get lost. For example, the documentation for simply expanding a keyword test with a form, so the tester can specify parameters there, is completely overblown and takes a while to be reduced to the important bits.
- The Name Mapping can be unstable when editing/renaming/moving objects and can lead to occasional crashes
- TestComplete is not fully dpi aware and can have difficulties when operating multiple screens with different resolutions, which can lead to "click" events not hitting the actual button, and the application itself can often be way too large or small when it sized itself based on a screen it is not located on.
- Mapping/interacting with objects is only possible when TestComplete can still find them after locating them. Therefore, when windows don't stay open after losing focus (by switching to TestComplete) this can be problematic, especially when trying to access elements that can not be pinpointed (either when they are not visible, have no visible representation, to begin with, or are situated below another object that blocks it)
- Improved product quality overall, since automating tedious tests frees up time and is not prone to fatigue
- When getting started - depending on the complexity of the software/UI tested - it can be a time sink before it brings actual value, and changes to the structure of the UI need to be communicated early, so the changes can be implemented on time to run the automation
- Once set up, the maintenance cost is low, and the automation frees up a lot of resources especially in an agile environment where there are a lot of releases that would need regression tests.
Do you think TestComplete delivers good value for the price?
Yes
Are you happy with TestComplete's feature set?
Yes
Did TestComplete live up to sales and marketing promises?
Yes
Did implementation of TestComplete go as expected?
Yes
Would you buy TestComplete again?
Yes