Forum Discussion

mfoster711's avatar
mfoster711
Regular Contributor
2 years ago

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 actions in a Desktop environment and then verifying the changes are also in the WEB environment. For example:

  • Add customer in Desktop app
  • Verify customer displays in WEB app
  • Update customer information in WEB app
  • Verify changes now show in Desktop app

This jumping back and forth between Desktop and WEB is a primary reason we use TestComplete since it supports both environments.

 

That being said, I plan to research what it would take to convert all of the WEB testing to Selenium. The challenge would be figuring out how to run tests that need to jump between TestComplete and Selenium. I would need to pass data between the two test environments which I would probably do using some type of temp file on the PC. I have no clue how I would run tests in a debug mode.

 

Also, I am not necessarily wanting to use the TestComplete method of calling Selenium tests which is dependent on using a framework with Selenium. I would probably create our own custom framework in Selenium.

 

Anyways, just curious if anybody has thoughts and suggestions on this.


  • -- Selenium cannot connect to the already running browser

    Actually you are not right as it does allow to connect and it depends on web browser implementation and not on Selenium specific. For example, you can connect to MSEdge existing session if the browser was started with debugging port opened. This should be possible for Chrome as both (Chrome and Edge) are fork of Chromium browser. But I am not sure if this possible in Firefox or Opera.

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3

      Hi,

       


      Bonibom wrote:

      [...] it depends on web browser implementation and not on Selenium specific.


       

      Agree. Actually, this was the reason for me to say that such approach sounds to me like some kind of non-standard use of web driver.

      Probably, I can re-phrase my initial statement like this:

      -- Selenium is just a library that makes it possible to emulate end-user actions or execute other code via injection to the controlled web page. Accessibility of all other functionality (and the amount of control over web page) depends on other libraries (including web driver) that are used in the given test project.

       

      P.S. I hope that the following automotive analogy is quite valid:

      TestComplete is like pickup - it can be used to carry people and goods, to drive on road and off road. All this to a certain extent of course. One cannot use if for racing or delivering wood logs to build the house. But it can be used as is for majority of regular every-day tasks.

      Selenium is like a basic assembly kit. It can do very little without other kits. One can build a wide range of different vehicles by combining this basic kit with other kits. But this requires time, certain knowledge and abilities to make kits to work together.

       

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi,

     

    Out of curiosity: Assuming you already have everything been setup for your operational environment in TestComplete, what is the reason to dispose it of and move to Selenium?

     

  • mfoster711's avatar
    mfoster711
    Regular Contributor

    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.

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3

      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.

       

      • mfoster711's avatar
        mfoster711
        Regular Contributor

        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's avatar
    mfoster711
    Regular Contributor

    I was also thinking about using the Test Engine REST API to perform all actions in our Desktop apps. This would allow me to have everything running in our Selenium framework and just make API calls as needed when performing actions in Desktop. 

     

    This sounds like a interesting option but I fear that using the Test Engine REST API might be going down a road that nobody travels. If I can't get Smartbear to address common issues with TestComplete in a timely manner, then what are the odds they would respond quickly to any issues encountered using the Test Engine REST API?