TestComplete and Selenium
Does anybody have suggestions or thoughts on using TestComplete along side Selenium? I perform a lot of testing in Desktop and WEB at the same time. Much of our our testing involves performing a...
Forum Discussion
Because of all of the issues with TestComplete recently and the complete failure of Smartbear to address any in a timely manner.
This has personally been the absolute worse timing for theses issues. My company is looking to greatly expand our use of automated testing. I convinced our management that TestComplete was the right tool for the future based on my 10+ years of using it. They were also considering a Selenium approach. We bought a company last year that uses Selenium for all of their automated testing and they use it quite well. But, since TestComplete can support Desktop and WEB, we decided on using TestComplete.
Right now, I am looking like an idiot to my management for recommending TestComplete. I am hoping to keep my job and I need to start exploring all other options, weighing the costs of those options and presenting my management with options.
If I can move our WEB testing to Selenium but still use TestComplete for desktop, that would possibly be the least amount of work for my team. Trying to go to a completely new tool (i.e. Ranorex, Katalon) would require us to re-write everything.
Well... My experience with TestComplete is 20+ years;), but, and I hate to say this, I can't but agree with your statements as for all problems that TestComplete has during past year... 😞
I don't think that sequential execution of TestComplete desktop tests and Selenium web tests will be a real challenge. All at all, you can still keep everything in TestComplete but replace the call to web test with the execution of Selenium test via command line.
Conceptual differences that I see between TestComplete and Selenium are:
-- TestComplete is a tool that provides all necessary infrastructure for tests (like log, execution tree, NameMapping (which is pretty close to Page Object model), etc.);
-- Selenium is a library that provides nothing but emulation of user actions over web elements. Thus, one should not think about Selenium only, but must think about a set of compatible libraries that will provide all required functionality (logging, access to test data, etc.);
-- As Selenium is just a library, it requires a driver that will execute the code. Majority of drivers are based on the unit-testing approach which means either test termination on first failure or custom efforts to make test not to terminate after first failure and still provide clear reporting about all failures that occur during test run;
-- Unit-test based architecture of drivers means that you will not be able to have something like Execution Plan from TestComplete. The sequence of your Selenium sub-tests must be (hard-)coded;
-- Selenium cannot connect to the already running browser. This means that you will not be able to do something in TestComplete, start browser and check result with Selenium, leave browser running, return to TestComplete and do something else, then start another Selenium test that will connect to the already running browser and reuse it. Instead, you will have to restart browser every time, put your web application into required state and only then proceed with actual actions that you need.
All the above might be not a problem for you as it depends on your tests architecture, but I thought that I should mention this anyway.
AlexKaras wrote:-- Selenium cannot connect to the already running browser.
I did not know this. Thanks for that information. I will keep it in mind.
I was planning to have my entire process driven by the Python code I right to work with Selenium. I currently use a custom framework we built to drive all our testing. I would convert this framework into python and use selenium webdriver commands for all WEB testing and call TestComplete to perform Desktop testing.
We use a keyword approach for our automated testing and our keyword testcases are actually built in Excel files. So, the amount of "code" is actually a lot less than somebody that builds all of their tests in TestComplete.
mfoster711 wrote:
AlexKaras wrote:-- Selenium cannot connect to the already running browser.
I did not know this. Thanks for that information. I will keep it in mind.
I think selenium can connect to an already running browser by --remote-debugging-port
atleast i have a test in our testcomplete project that does following:
- starts our desktop application and initiates login process [this step is executed with testcomplete]
-> WebView2 window opens (which is edge embedded in a webview2 window)
- starts our selenium login test via commandline (nunit + selenium c# + edgedriver)
-> selenium test then does the following: connects to the already running webview2 window by remote debugging port and executes the login steps
Not sure for other browsers but i think chromium based browsers have the --remote-debugging-port option that allows the webdriver to attach itself to the running browser instance
For an example see -> https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/webdriver
