This library contains helper functions that can be used together with Protractor for creating robust end-to-end tests.
Many of the helper functions on this library uses protractor.ExpectedConditions to ensure that the elements we want to interact with are in the correct state before interacting with them or running expectations on them. This helps on avoiding trying to interact with elements when they are still not ready for it, which helps on avoiding test flakiness.
-
Open to see all available helpers
setTimeoutisCurrentUrlDifferentFromBaseUrlwaitForAlertToBePresentwaitForElementPresencewaitForElementNotToBePresentwaitForElementVisibilitywaitForElementNotToBeVisibleclickhoverAndClickfillFieldWithTextfillFieldWithTextAndPressEnteruploadFileIntoInputFieldclearclearFieldAndFillItWithTexttapwaitForTextToBePresentInElementwaitForTextNotToBePresentInElementwaitForUrlToBeEqualToExpectedUrlwaitForUrlNotToBeEqualToExpectedUrlwaitForUrlToContainStringwaitForUrlNotToContainStringscrollToElement
Let's say you want to create a test for the sign in happy path of an example application.
Without this library the test could be written as something like this:
const EC = protractor.ExpectedConditions;
const DEFAULT_TIMEOUT_IN_MS = 5000;
describe("Sign in page", () => {
it("successful sign in", () => {
browser.get("https://example.com/sign-in");
const emailField = element(by.id("email"));
const passwordField = element(by.id("password"));
const signinButton = element(by.id("signin"));
browser.wait(EC.visibilityOf(emailField), DEFAULT_TIMEOUT_IN_MS);
browser.wait(EC.visibilityOf(passwordField), DEFAULT_TIMEOUT_IN_MS);
browser.wait(EC.elementToBeClickable(signinButton), DEFAULT_TIMEOUT_IN_MS);
emailField.sendKeys("valid@email.com");
passwordField.sendKeys("validpassword");
signinButton.click();
const avatar = element(by.id("avatar"));
browser.wait(EC.visibilityOf(avatar), DEFAULT_TIMEOUT_IN_MS);
expect(avatar.isDisplayed()).toBe(true);
});
});The same test could be written as below, using the protractor-helper library.
const protractorHelper = require("protractor-helper");
describe("Sign in page", () => {
it("successful sign in", () => {
browser.get("https://example.com/sign-in");
const emailField = element(by.id("email"));
const passwordField = element(by.id("password"));
const signinButton = element(by.id("signin"));
protractorHelper.fillFieldWithText(emailField, "valid@email.com");
protractorHelper.fillFieldWithText(passwordField, "validpassword");
protractorHelper.click(signinButton);
const avatar = element(by.id("avatar"));
protractorHelper.waitForElementVisibility(avatar);
});
});As you can see, by using the protractor-helper library the code is easier to read. Also, there is no need of unnecessary complexity.
Below it is described the process of Installation of such module.
Run npm install protractor-helper --save-dev to install the library as a dev dependency of your project.
After installing the library you will need to require it in your test file (see below).
// foobar.spec.js
const protractorHelper = require("protractor-helper");As soon as you have the library required in your test file you can start using its helper methods.
Here you'll find examples of usage of each of the available helper methods. (Important: read the notes on the top)
Below is the list of all available helpers in this library with your respective example:
This method allows to change the timeout duration of all protractor-helper methods called below setTimeout.
The timeoutInMilliseconds default is 5000 milliseconds
If called without passing an argument the timeout will be set to the default one.
An example of using this method is the need to ensure the screen loads within up to XX seconds, due to the request of the product management. This commonly occurs in ecommerce systems on special dates, such as Black Friday.
This method returns a boolean depending if the current url is different from the base url. No argument needed. Example
This method waits for an alert to be present on the page. Example
This method waits for an element to be present in the DOM.
Note: An element may be present but not displayed. If you want to wait for the element to be displayed use the method
waitForElementVisibility.
This method is the opposite of the previous one, so, it waits for an element not to be present in the DOM. Example
This method waits for an element to be visible in the page. Being displayed means not only that the element is present in the DOM, but also that is has a height and width that is greater than 0. Example
This method is the opposite of the previous one, so, it waits for an element not to be visible in the page. By saying not being displayed means that the element may be in the DOM, but not visible. Example
This method is used to click in an element as soon as it is in a clickable state. This means that the element is visible and enabled for clicking. Example
This method is used to hover over an element as soon as it is present in the DOM, and then click on it. Example
This method fills an input field with a text as soon as such field is visible. Example
This method fills an input field with a text as soon as such field is visible and then it simulates pressing the ENTER key from the keyboard. This method is useful in cases such as when doing a search and pressing the ENTER key, instead of having to fill the input field and clicking the search button, for example. Example
This method uploads a file in a file input field as soon as the file input field is present in the DOM. Example
This method clears a text input field as soon as such field is visible. Example
This method clears a text input field as soon as such field is visible, and then it fills it with a text. Example
This method performs a tap action on a clickable/tappable HTML element as soon as it is in a clickable/tappable state. This method is used when performing web mobile testing in mobile emulators, for example. Example
This method waits for a specific text to be present in a specific HTML element. Example
This method is the opposite of the previous one, so, it waits for a specific text not to be present in a specific HTML element. Example
This method waits for the URL to be equal to an expected URL. Such method is useful when you want to continue performing actions on elements only when in the correct URL. Example
This method waits for the URL not to be equal to an expected URL. Such method is useful when you want to continue performing actions on elements only when not in a specific URL. Example
This method waits for the URL to contain an expected string. Such method is useful when you want to perform verifications based on the current URL. Example
This method waits for the URL not to contain an expected string. Such method is useful when you want to perform verifications based on the current URL. Example
This method is used to scroll up to an element on the page as soon as the element is visible in the DOM. Example
Some of the available methods in this library can be used as test expectations, meaning that when using them you don't necessarily need to add an explicit expectation, such as something like this: expect(avatar.isDisplayed()).toBe(true);.
By using the protractor-helper library this could be implicit, like this: protractorHelper.waitForElementVisibility(avatar);. Here, implicit means that if the function waitForElementVisibility(avatar) has passed, it means that the element is visible, in other words, the element is displayed.
Below you can find the list of methods that can be used as expectations:
waitForElementPresence(element)waitForElementNotToBePresent(element)waitForElementVisibility(element)waitForElementNotToBeVisible(element)waitForTextToBePresentInElement(element, text)waitForTextNotToBePresentInElement(element, text)waitForUrlToBeEqualToExpectedUrl(expectedUrl)waitForUrlNotToBeEqualToExpectedUrl(expectedUrl)waitForUrlToContainString(string)waitForUrlNotToContainString(string)
Note: if you use such methods as expectations they will not count as expectations, in a test report, for example, but if they fail a clear message will be shown to ease understanding why the test has failed. In the end, test reports are usually useful in cases where tests have failed and we need to understand why. If all tests are green there is nothing to worry about, at least not if they were well implemented.
Let's look how a failure would looks like when using some of this methods as expectations.
- Failure when using
waitForElementPresenceas expectation:
Failed: element with locator 'By(css selector, *[id="foo"])' is not present.- Failure when using
waitForElementVisibilityas expectation:
Failed: element with locator 'By(css selector, *[id="foo"])' is not visible.- Failure when using
waitForTextToBePresentInElementas expectation:
Failed: text 'foo' not present on element with locator 'By(css selector, h1)'.As you can see, the messages are clear and tell you exactly why the test has failed, such as in the previous example, where a specific text ('foo') is not present in a heading element (an element with css selector 'h1').
Here we list some external resources such as blog posts that mention the protractor-helper library.
- Launch of protractor-helper v4 - Breaking changes
- Release of protractor-helper version 4.1.1 - Types definitions in the functions’ signatures
- Why you shouldn't use sleeps in automated tests (PT-BR)
Checkout the code of conduct.
The protractor-helper library was created by Walmyr Filho and is kept together with Paulo Gonçalves.
Follow them on Twitter (@walmyrlimaesilv and @paulorgoncalves.)
Thanks also to Lucas Amaral, Michiel Cuijpers, Ghazi Khan, Pedro Hyvo, Urvi Koladiya, and Zidrex Andag for contributing to the project.