2 years ago we used TC for testing a fat desktop app, since then we've only made small desktop apps, which we test with winapp driver and selenium on win10 in developer mode. I use Accessibility Insight to identify the buttons and forms. I can write tests in Visual Studio Code with the app and AI on the side and run tests in console.
Then back to TC I've moved the fat app tests to win10 and it is working fine, except for the cumbersome way of having to go into the recorder or named mapping and explicitly add the button forms. Takes way longer time. If they could be standalone on the side, so I do not have to move away from the code all the time, would save me lots of time.
My impression is that selenium with webappdriver is very good at small apps (faster than TestExecute), but it is unstable on larger projects. Therefore TC far more reliable.
Webtesting do not use TC, we do it with linux containers.
Got it. And thank you for sharing your experience with it.
Well... You know TestComplete and know that the recommended way to create test code is to examine tested functionality (forms and controls and access to their data) using Object Browser and create Aliases tree first. It is not required to map each and every entity you will need to interact with in your test code. Instead, you may create just a convenient partial 'skeleton' and use it as a starting point for dynamic search of other controls. (E.g. map form, its grid and OK button but do a dynamic search for data within the grid.)
However, it is quite OK to create test code that is not based on Aliases.
I think that you may investigate how identification information provided by Accessibility Insights can be mapped to the information required by TestComplete to search for controls (property names and corresponding values) and use Accessibility Insights then instead of Object Browser.