TestComplete and Selenium

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.

 

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.