Test automation of WPF-based application with TestComplete
January 20, 2022

Test automation of WPF-based application with TestComplete

Anonymous | TrustRadius Reviewer
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

To really make the most of TestComplete, at least some scripting is necessary. TestComplete works really well with clearly identifiable objects but needs some tweaking for objects that vary in e.g. quantity. We have some elements that vary, but the vast majority of UI elements have unique identifies, and those iterative elements can also be mapped to iterations of a semi-unique element (so more of a mapping of the item type that the specific item). I doubt the usability would be near as good if more items were not clearly identifiable. In our case, most are, and we handle our tests in form of nested keyword tests that occasionally also implement scripting when needed. Tedious tests like Verification of the correct presence and status of UI elements in all possible scenarios, and iterative tests of e.g. input values and combinations of such, are made easy to set up, execute and evaluate.