New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is portractor a dependency? #6

Closed
dogoku opened this Issue Nov 29, 2016 · 20 comments

Comments

6 participants
@dogoku

dogoku commented Nov 29, 2016

Is protractor a dependency or can webdriver.io be used instead?

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Nov 29, 2016

Owner

Right now finding of the on-screen elements happens via protractor, but other than that the library could be driver agnostic.

Could you please elaborate a bit more on the benefits of using webdriver.io directly instead of protractor?

Thanks,
Jan

Owner

jan-molak commented Nov 29, 2016

Right now finding of the on-screen elements happens via protractor, but other than that the library could be driver agnostic.

Could you please elaborate a bit more on the benefits of using webdriver.io directly instead of protractor?

Thanks,
Jan

@dogoku

This comment has been minimized.

Show comment
Hide comment
@dogoku

dogoku Nov 30, 2016

There are a few reasons why I'd rather use webdriver.io (or selenium-webdriver) over protractor.

  1. The most important reason is that we already have automated tests running using webdriver.io and we simply want to add serenity-js to our tool-chain, without having to change a lot of things. Existing tests should ideally remain unaffected until we choose to rewrite them using serenity.

  2. Dont need all the extra angular specific features added by protractor. This might not sound as a real reason, but the leaner your tests the better if you are running 100s of tests on multiple environments. Furthermore, at the moment you need to add protractor.browser.ignoreSynchronization = true; to your tests in order for protractor to stop checking for angular.

  3. Yet another dependency. Having a dependency on an additional project (protractor) and all the headache that comes with it (configuration, bugs, etc).

  4. Magic globals. Protractor exposes a number of global methods in an attempt to be helpful. This "magic" is something we would like to avoid. With webdriver.io (as a standalone package) and selenium-webdriver you have to explicitly require the package and create a browser instance, which in our opinion is a much cleaner approach, as our dependencies are clearly defined. Protractor has a noGlobals config option, which puts all globals under a single protractor namespace.

  5. We want to manage selenium instances. With the current setup, protractor is using webdriver-manager to download, update and spin-up selenium instances. Protractor has good config for using existing selenium instances or even remote selenium services (saucelabs etc).

dogoku commented Nov 30, 2016

There are a few reasons why I'd rather use webdriver.io (or selenium-webdriver) over protractor.

  1. The most important reason is that we already have automated tests running using webdriver.io and we simply want to add serenity-js to our tool-chain, without having to change a lot of things. Existing tests should ideally remain unaffected until we choose to rewrite them using serenity.

  2. Dont need all the extra angular specific features added by protractor. This might not sound as a real reason, but the leaner your tests the better if you are running 100s of tests on multiple environments. Furthermore, at the moment you need to add protractor.browser.ignoreSynchronization = true; to your tests in order for protractor to stop checking for angular.

  3. Yet another dependency. Having a dependency on an additional project (protractor) and all the headache that comes with it (configuration, bugs, etc).

  4. Magic globals. Protractor exposes a number of global methods in an attempt to be helpful. This "magic" is something we would like to avoid. With webdriver.io (as a standalone package) and selenium-webdriver you have to explicitly require the package and create a browser instance, which in our opinion is a much cleaner approach, as our dependencies are clearly defined. Protractor has a noGlobals config option, which puts all globals under a single protractor namespace.

  5. We want to manage selenium instances. With the current setup, protractor is using webdriver-manager to download, update and spin-up selenium instances. Protractor has good config for using existing selenium instances or even remote selenium services (saucelabs etc).

@nbarrett

This comment has been minimized.

Show comment
Hide comment
@nbarrett

nbarrett Nov 30, 2016

Contributor

I would have thought this might be a compelling reason too?
'Working with elements on a page has never been easier due to its synchronous nature. When fetching or looping over elements you can use just native JavaScript functions. With the $ and $$ functions WebdriverIO provides useful shortcuts which can also be chained in order to move deeper in the DOM tree without using complex xPath selectors.'

Contributor

nbarrett commented Nov 30, 2016

I would have thought this might be a compelling reason too?
'Working with elements on a page has never been easier due to its synchronous nature. When fetching or looping over elements you can use just native JavaScript functions. With the $ and $$ functions WebdriverIO provides useful shortcuts which can also be chained in order to move deeper in the DOM tree without using complex xPath selectors.'

@dogoku

This comment has been minimized.

Show comment
Hide comment
@dogoku

dogoku Nov 30, 2016

I'd actually argue that's a reason against using webdriver.io test runner. I prefer requiring the webdriverio package and controlling what's get added to the global scope.

Depending on $ and $$ magically being there (and behaving exactly as they do), means that your tests will break if run with something other than their test runner. Put simply, if something isn't explicitly required, it shouldn't be there.

dogoku commented Nov 30, 2016

I'd actually argue that's a reason against using webdriver.io test runner. I prefer requiring the webdriverio package and controlling what's get added to the global scope.

Depending on $ and $$ magically being there (and behaving exactly as they do), means that your tests will break if run with something other than their test runner. Put simply, if something isn't explicitly required, it shouldn't be there.

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Nov 30, 2016

Owner

I agree with your sentiment regarding the magic globals; they also limit the opportunity for writing multi-user (as in multi-browser) tests.
In fact, Serenity/JS limits the "blast radius" of the Protractor global objects thanks to the BrowseTheWeb ability.

The way I was thinking of supporting webdriver.io (which is a cool idea, especially for the guys developing React, Aurelia, etc. apps, which don't need the angular-specific protractor features) is that we'd need a serenity-webdriver package, with its own implementation of BrowseTheWeb and the Target class.

Some JavaScript/TypeScript API for configuring the library would also be useful. For example, for the Protractor version there's the SerenityProtractorPlugin, which configures the reporters, etc. We'd need something like that for the webdriver.io version as well.

The selenium/webdriver management capability provided by protractor is entirely optional, I tend to invoke it from an NPM script, so that it doesn't pollute the tests.

With the $ and $$ selectors - I'd probably approach them in a similar manner as the global protractor element selector - hide them behind a webdriver.io-specific Target abstraction.

Thoughts?

Owner

jan-molak commented Nov 30, 2016

I agree with your sentiment regarding the magic globals; they also limit the opportunity for writing multi-user (as in multi-browser) tests.
In fact, Serenity/JS limits the "blast radius" of the Protractor global objects thanks to the BrowseTheWeb ability.

The way I was thinking of supporting webdriver.io (which is a cool idea, especially for the guys developing React, Aurelia, etc. apps, which don't need the angular-specific protractor features) is that we'd need a serenity-webdriver package, with its own implementation of BrowseTheWeb and the Target class.

Some JavaScript/TypeScript API for configuring the library would also be useful. For example, for the Protractor version there's the SerenityProtractorPlugin, which configures the reporters, etc. We'd need something like that for the webdriver.io version as well.

The selenium/webdriver management capability provided by protractor is entirely optional, I tend to invoke it from an NPM script, so that it doesn't pollute the tests.

With the $ and $$ selectors - I'd probably approach them in a similar manner as the global protractor element selector - hide them behind a webdriver.io-specific Target abstraction.

Thoughts?

@dogoku

This comment has been minimized.

Show comment
Hide comment
@dogoku

dogoku Dec 1, 2016

After spending a bit more time with protractor I've updated my list of reasons since protractor offers configuration that addresses my concerns (namely magic globals and selenium instances)

Yeah, I believe different implementations will be required to be made on serenity level, to abstract away differences between selenium-webdriver and webdriver.io APIs and specific guidelines on how to write your serenity logic to leverage those abstractions.

However if that proves to be too time consuming, supporting selenium-webdriver on its own, without protractor, should be a much easier to achieve while still removing the protractor dependency.

dogoku commented Dec 1, 2016

After spending a bit more time with protractor I've updated my list of reasons since protractor offers configuration that addresses my concerns (namely magic globals and selenium instances)

Yeah, I believe different implementations will be required to be made on serenity level, to abstract away differences between selenium-webdriver and webdriver.io APIs and specific guidelines on how to write your serenity logic to leverage those abstractions.

However if that proves to be too time consuming, supporting selenium-webdriver on its own, without protractor, should be a much easier to achieve while still removing the protractor dependency.

@jan-molak jan-molak added the question label Jan 22, 2017

@nicojs

This comment has been minimized.

Show comment
Hide comment
@nicojs

nicojs Feb 20, 2017

As an addition to the Yet another dependency reason: protractor itself has a lot of dependencies!

For example, it might break a typescript build, because of the @typings dependencies that comes with it. They pollute your global typescript scope with expect, it and its jasmine brothers. Of course you can opt-out of this in your typescript config, but its a pain nevertheless.

nicojs commented Feb 20, 2017

As an addition to the Yet another dependency reason: protractor itself has a lot of dependencies!

For example, it might break a typescript build, because of the @typings dependencies that comes with it. They pollute your global typescript scope with expect, it and its jasmine brothers. Of course you can opt-out of this in your typescript config, but its a pain nevertheless.

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Feb 20, 2017

Owner

Hey guys and thanks so much for your feedback and ideas!

Protractor provides a number of nice features, such as:

  • a test runner - the protractor CLI is already supported by a number of modern IDEs so that you're not restricted to executing the tests from the command line
  • webdriver manager - which takes care of downloading the webdriver binaries and the selenium standalone server
  • webdriver instance management - every test is given an instance of a protractor.browser so that we don't need to manage it explicitly
  • parallel test execution - protractor tests can run in sharded mode, which greatly speeds up the execution
  • angular-specific browser synchronisation - so that the test doesn't have to explicitly wait for an XHR request to complete, for example
  • element selectors optimised for angular projects
  • integration with SauceLabs and BrowserStack clouds

I agree that protractor has quite a few dependencies and the way the guys handle @typings could be improved (having said that, Protractor 5.1 has already implemented some of the improvements, by removing the dependency on Jasmine typings for example).

Like I said earlier, the only Serenity/JS module that requires Protractor is serenity-protractor, so it's definitely a possibility to have a serenity-webdriver module that uses either selenium-webdriver or webdriver.io under the hood, therefore limiting the number of dependencies Serenity/JS has.

However, this would mean that Serenity/JS would have to operate in dual mode - both as a Protractor extension and standalone. In a standalone mode it would have to either:

  • assume that since you don't want to be using Protractor:
    • you most likely don't test an Angular project so don't need Angular-specific features like selectors or browser synchronisation
    • you already have a webdriver infrastructure set up, and can provide Serenity/JS with an instance of a webdriver-compatible browser
    • you will only require a basic test runner on top of what Serenity/JS already provides to invoke your tests and enable Webdriver ControlFlow synchronisation
  • become a more generic version of Protractor that supports Angular and non-Angular projects
    • this seems like an overkill and is propably a bit outside of the scope for this project :-)

Thoughts?

Owner

jan-molak commented Feb 20, 2017

Hey guys and thanks so much for your feedback and ideas!

Protractor provides a number of nice features, such as:

  • a test runner - the protractor CLI is already supported by a number of modern IDEs so that you're not restricted to executing the tests from the command line
  • webdriver manager - which takes care of downloading the webdriver binaries and the selenium standalone server
  • webdriver instance management - every test is given an instance of a protractor.browser so that we don't need to manage it explicitly
  • parallel test execution - protractor tests can run in sharded mode, which greatly speeds up the execution
  • angular-specific browser synchronisation - so that the test doesn't have to explicitly wait for an XHR request to complete, for example
  • element selectors optimised for angular projects
  • integration with SauceLabs and BrowserStack clouds

I agree that protractor has quite a few dependencies and the way the guys handle @typings could be improved (having said that, Protractor 5.1 has already implemented some of the improvements, by removing the dependency on Jasmine typings for example).

Like I said earlier, the only Serenity/JS module that requires Protractor is serenity-protractor, so it's definitely a possibility to have a serenity-webdriver module that uses either selenium-webdriver or webdriver.io under the hood, therefore limiting the number of dependencies Serenity/JS has.

However, this would mean that Serenity/JS would have to operate in dual mode - both as a Protractor extension and standalone. In a standalone mode it would have to either:

  • assume that since you don't want to be using Protractor:
    • you most likely don't test an Angular project so don't need Angular-specific features like selectors or browser synchronisation
    • you already have a webdriver infrastructure set up, and can provide Serenity/JS with an instance of a webdriver-compatible browser
    • you will only require a basic test runner on top of what Serenity/JS already provides to invoke your tests and enable Webdriver ControlFlow synchronisation
  • become a more generic version of Protractor that supports Angular and non-Angular projects
    • this seems like an overkill and is propably a bit outside of the scope for this project :-)

Thoughts?

jan-molak added a commit that referenced this issue May 20, 2017

feat(core): @serenity/core is no longer dependent on Protractor
affects: @serenity-js/core

First step towards supporting #40 and #6
@DeChrish

This comment has been minimized.

Show comment
Hide comment
@DeChrish

DeChrish May 30, 2017

Testing Non-Angular webpage.
How to resolve the below error:
Error: Error while waiting for Protractor to sync with the page: "window.angular is undefined.

DeChrish commented May 30, 2017

Testing Non-Angular webpage.
How to resolve the below error:
Error: Error while waiting for Protractor to sync with the page: "window.angular is undefined.

@nicojs

This comment has been minimized.

Show comment
Hide comment
@nicojs

nicojs May 30, 2017

@DeChrish

How to resolve the below error: Error: Error while waiting for Protractor to sync with the page: "window.angular is undefined.

Add browser.ignoreSynchronization = true in a Before step.

nicojs commented May 30, 2017

@DeChrish

How to resolve the below error: Error: Error while waiting for Protractor to sync with the page: "window.angular is undefined.

Add browser.ignoreSynchronization = true in a Before step.

@DeChrish

This comment has been minimized.

Show comment
Hide comment
@DeChrish

DeChrish May 30, 2017

@nicojs Thanks, but i don't find any hooks in the below repo https://github.com/serenity-js/tutorial-from-scripts-to-serenity.
When i was trying to add the above Sync line in one of tasks/start file, it still throws error.

Do i need to add hooks.ts and test this?

DeChrish commented May 30, 2017

@nicojs Thanks, but i don't find any hooks in the below repo https://github.com/serenity-js/tutorial-from-scripts-to-serenity.
When i was trying to add the above Sync line in one of tasks/start file, it still throws error.

Do i need to add hooks.ts and test this?

@DeChrish

This comment has been minimized.

Show comment
Hide comment
@DeChrish

DeChrish May 31, 2017

@nicojs this helps after adding in config
onPrepare: function () { /** * If you are testing against a non-angular site - set ignoreSynchronization setting to true * * If true, Protractor will not attempt to synchronize with the page before * performing actions. This can be harmful because Protractor will not wait * until $timeouts and $http calls have been processed, which can cause * tests to become flaky. This should be used only when necessary, such as * when a page continuously polls an API using $timeout. * * @type {boolean} */ browser.ignoreSynchronization = true; }

DeChrish commented May 31, 2017

@nicojs this helps after adding in config
onPrepare: function () { /** * If you are testing against a non-angular site - set ignoreSynchronization setting to true * * If true, Protractor will not attempt to synchronize with the page before * performing actions. This can be harmful because Protractor will not wait * until $timeouts and $http calls have been processed, which can cause * tests to become flaky. This should be used only when necessary, such as * when a page continuously polls an API using $timeout. * * @type {boolean} */ browser.ignoreSynchronization = true; }

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak May 31, 2017

Owner

@nicojs, @DeChrish please have a look at my recent article "Cross-application testing with Serenity/JS" as well as the Journey Planner demo project, which demonstrates testing non-Angular apps. Hope this helps!

Owner

jan-molak commented May 31, 2017

@nicojs, @DeChrish please have a look at my recent article "Cross-application testing with Serenity/JS" as well as the Journey Planner demo project, which demonstrates testing non-Angular apps. Hope this helps!

@DeChrish

This comment has been minimized.

Show comment
Hide comment
@DeChrish

DeChrish Jun 2, 2017

@jan-molak Thanks for the demo project. working with adobe's crx. quite complex DOM.

DeChrish commented Jun 2, 2017

@jan-molak Thanks for the demo project. working with adobe's crx. quite complex DOM.

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Jun 2, 2017

Owner

@DeChrish Interesting! I'd love to hear what your experience was!

Owner

jan-molak commented Jun 2, 2017

@DeChrish Interesting! I'd love to hear what your experience was!

@DeChrish

This comment has been minimized.

Show comment
Hide comment
@DeChrish

DeChrish Jun 2, 2017

@jan-molak yeah sure, I am not able to find any open container for aem crx. Keep you posed with simple flow.
In a nutshell, with CRX components (web elements) are created in crx (backend) and packaged to author's and author's will drag&drop component in webpage and updated the properties of the component and publish the component. Then the component will be used by angular code for final view. Author Port in web server is different from Publish Port.

DeChrish commented Jun 2, 2017

@jan-molak yeah sure, I am not able to find any open container for aem crx. Keep you posed with simple flow.
In a nutshell, with CRX components (web elements) are created in crx (backend) and packaged to author's and author's will drag&drop component in webpage and updated the properties of the component and publish the component. Then the component will be used by angular code for final view. Author Port in web server is different from Publish Port.

@jan-molak jan-molak added the ready label Jun 9, 2017

@jan-molak jan-molak closed this in 5dc4dd1 Jun 11, 2017

@jan-molak jan-molak removed the ready label Jun 11, 2017

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Jun 11, 2017

Owner

Hey @dogoku, @nicojs - @serenity-js/core is now available as a protractor-independent module. This should hopefully make plugging Serenity/JS into other test runners much easier!

Owner

jan-molak commented Jun 11, 2017

Hey @dogoku, @nicojs - @serenity-js/core is now available as a protractor-independent module. This should hopefully make plugging Serenity/JS into other test runners much easier!

@san-ouadghiri

This comment has been minimized.

Show comment
Hide comment
@san-ouadghiri

san-ouadghiri Apr 30, 2018

Hi @jan-molak , @dogoku , @nicojs ,
Is there anywhere I can find -even the most basic- example of a serenity project plug-ed to anything else than protractor (ex. webdriver.io)? Just to have an understanding on how this can actually be done. Would be a nice thing to add to the current documentation.

San.

san-ouadghiri commented Apr 30, 2018

Hi @jan-molak , @dogoku , @nicojs ,
Is there anywhere I can find -even the most basic- example of a serenity project plug-ed to anything else than protractor (ex. webdriver.io)? Just to have an understanding on how this can actually be done. Would be a nice thing to add to the current documentation.

San.

@jan-molak

This comment has been minimized.

Show comment
Hide comment
@jan-molak

jan-molak Apr 30, 2018

Owner

@san-ouadghiri I'm working on an example demonstrating integrating Serenity/JS with Jest and Enzyme as we speak, stay tuned!

Owner

jan-molak commented Apr 30, 2018

@san-ouadghiri I'm working on an example demonstrating integrating Serenity/JS with Jest and Enzyme as we speak, stay tuned!

@san-ouadghiri

This comment has been minimized.

Show comment
Hide comment
@san-ouadghiri

san-ouadghiri Apr 30, 2018

@jan-molak > youhou \o/ -pop the champaign-

san-ouadghiri commented Apr 30, 2018

@jan-molak > youhou \o/ -pop the champaign-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment