DEV Community: Endtest

How To Record Automated Tests For Mobile Apps

endtest — Wed, 18 Mar 2020 13:48:00 +0000

Endtest allows you to create, manage and execute Automated Tests, without having to write any code.

You can use the open-source Endtest Chrome Extension to record a test for your website directly in the browser.

But did you know that you can also record tests for native and hybrid Android and iOS applications? 🤗

And you do that direcly from your browser.

What? 😱

That's right.

The Mobile Recorder allows you to record tests for native and hybrid mobile apps, directly in your browser.

What are the steps?

You upload the APK or IPA file.
The app is installed on a real mobile device.
The information for each element is extracted.
An interactive preview is shown in real-time in your browser window.
You record the test.
You save the test.

But how does it locate the elements?

It's no secret that our engine for Mobile Tests is using Appium.

We just fetch the locators for the elements that you interact with.

If we would rely on image recognition, that would lead to brittle tests.

We fetch the following locators:
• ID
• Accessibility ID
• Name
• Class Name
• XPath
• Coordinates

If you're not using Coordinates, you can easily execute the same test on different devices.

Coordinates are only used in extreme cases, when no other unique locator is available.

You can find more details in our Documentation.

Building The Most Powerful Test Recorder On The Market

endtest — Fri, 21 Feb 2020 15:09:14 +0000

Introduction

Endtest allows you to create, manage and execute Automated Tests, without having to write any code.

You can use the Endtest Chrome Extension to record a test directly in the browser.

And yes, it's open-source and free to use. 🤗

This extension works by recording all the steps that a user performs in the browser and converts those steps into an automated test.

1. How we record the steps

We record the following actions:
• Click
• Right Click
• Write Text
• Select option from dropdown
• Press Key
• Hover
• Scroll
• Open tab
• Close tab
• Switch to next tab
• Switch to previous tab
• Go back
• Go forward
• Access URL from navigation bar
• Entering an iframe
• Exiting an iframe
... and many more

Since we're talking about a Chrome extension, the only way to detect such events is through JavaScript and the Chrome API.

We used different JavaScript event listeners such as onclick, onchange, onkeyup, onmousemove, etc to figure out what the user does.

It's important to distinguish between the different actions.

For example, when a user is typing inside an input, you need to register that as a "Write Text" action.

But when the user pressed the Enter key or the Escape key, you need to register that as a "Press Key" action.

The user has the option to enable or disable the detection of Hover and Scroll events, since they're not relevant in all situations.

Even if a user enables the detection of Hover events, they will only be logged if the duration of Hover is above a certain number of miliseconds.

This is done to avoid recording unnecessary Hover events when the user is simply moving the pointer.

The Chrome API is used to detect actions which cannot be detected with JavaScript, such as when the user is opening a new tab or switching focus to a different tab.

2. Getting the right permissions

Being able to record everything that a user does in the browser might sound like a job for the NSA.

Luckily, Chrome is smart enough to let you declare what permissions you need in the manifest.json file.

They also review those permissions when you publish the extension in the Chrome Web Store.

And the user is informed about those permissions when installing the extension.

Here is what the permissions for our extension like:

  "permissions": [
    "activeTab", "<all_urls>","cookies","storage","tabs","webNavigation"
  ],

3. Locating the elements

It's no secret that our engine for Web Tests is using Selenium.

That's why we need to fetch locators for the elements that the users interacts with.

If we would rely on coordinates or image recognition, that would lead to brittle tests.

We fetch the following locators:
• ID
• Name
• CSS Selector
• XPath

Fetching the ID for an element might seem as simple as this:

window.onclick = function(e) {
   the_id = e.target.id;
}

But there are plenty of tricky situations:

The element does not have an ID
Multiple elements share the same ID
The ID is generated dynamically and changes with each refresh

This means that we always check for uniqueness and we try to detect and avoid using IDs which are dynamic.

The same rules apply for the Name attribute.

CSS Selectors can be generated by using the using the attributes from an element and the parent nodes.

Let's take a look at this example:

<html>
   <body>
      <div class="login-form">
         <input id="mat-input-6" type="text" placeholder="Email">
         <input id="mat-input-9" type="password" placeholder="Password">
      </div>
   </body>
</html>

We can easily spot that the IDs are dynamic, so we have to avoid them.

The basic CSS Selector for the Email input would look like this:

body > div > input[type=text]:nth-child(1)

But we can easily construct something more reliable:

input[placeholder="Email"]

Most people ditch XPaths for CSS Selectors, thinking that they're just as powerful, but slower. Big mistake.

XPaths have some hidden tricks up their sleeves.

The XPath equivalent to the previous CSS Selector would look like this:

//input[@placeholder = "Email"]

But here's a situation where XPath can save your life:

<html>
   <body>
      <ul class="items">
         <li class="item">Apple</li>
         <li class="item">Orange</li>
         <li class="item">Banana</li>
      </ul>
   </body>
</html>

Let's try to fetch a locator for the Orange list item.

CSS Selectors do not have the ability to locate an element based on the text, but XPaths do.

The XPath for the Orange list item is:

//li[contains(text(),'Orange')]

We even offer advanced settings for detecting locators:

Using classes in CSS Selectors and XPaths can also be tricky, since they can only appear in the element when you click on it.

Let's take a look at this example:

<html>
   <body>
      <div class="container">
         <input type="button" class="login-form">
      </div>
   </body>
</html>

We want to locate the input type="button" element.

But when we click on that input, it gets 2 extra classes:

<html>
   <body>
      <div class="container">
         <input type="button" class="login-form active focus">
      </div>
   </body>
</html>

Since we're recording the event at the moment of the click, our Chrome Extension would record the element as having 2 extra classes.

If this would happen, our engine would throw an "Element not found" error when the test would be executed, since those 2 extra classes are not appended if the element isn't clicked.

That's why allow the users to have a list of classes that our Chrome Extension can simply ignore:

4. Going the extra mile

We always make sure our users get the best experience.

Steps for taking screenshots and adding assertions can be added directly from the recorder.

The recording process can also be paused and resumed.

You can find more details in our Documentation

Q&A

1. Why do we also offer a cross-browser cloud infrastructure?

We take testing very seriously.

That's why our cloud platform offers real browsers on Windows and macOS machines and mobile devices.

We encourage developers to avoid using headless browsers on Linux machines for their automated tests, since those browsers do not have the same behavior as the real browsers used by users.

2. Why record the tests with JavaScript and execute them with Selenium?

Since our recorder had to be a Chrome extension, we had no other choice than to use JavaScript.

Our engine for Web Tests is using Selenium, because it's open-source, constantly improved, mimics real user behavior and it works with all the major browsers.

We advise developers to avoid using JavaScript-based libraries for executing automated tests in the UI, since those libraries have severe limitations and do not mimic real user behavior.

For example, a JavaScript-based library for testing the UI can easily click on an element which is completely covered by another element.
A real user and a Selenium test cannot do that.

A JavaScript library for testing the UI cannot perform file uploads, cannot manage iframes and cannot manage multiple browser tabs.

Currently, there isn't any JavaScript library for UI testing that works on all the major browsers and devices.

How to integrate Endtest with BrowserStack

Klaus — Wed, 25 Sep 2019 14:25:54 +0000

Introduction

Endtest allows you to create, manage and execute Automated Tests, without having to write any code.

By integrating with BrowserStack, you can execute Mobile Tests created with Endtest on a range of real Android and iOS mobile devices offered by BrowserStack.

Getting Started

1) Go to your BrowserStack account.
2) Click on App Automate from the Products section:

3) Click on the Show button from the Username and Access Keys section from the left side of the page:

4) Go to the Settings page from Endtest.
5) Add the Username and Access Key from BrowserStack App Automate in the BrowserStack User and BrowserStack Key inputs from the Endtest Settings page.

6) Click on the Save button.

Nice job! Your Endtest account is now connected with your BrowserStack account.

Running your first test

1) Upload your APK or IPA file in the Drive section from Endtest.

2) After that, go to the Mobile Tests section and click on the Run button.

3) Select BrowserStack from the Grid dropdown.

4) Select the Platform and the Real Device on which you want to execute your test on.

5) Select your APK file in the APK Download URL input.
If you select an iOS device, the APK Download URL input would be replaced with the IPA Download URL input.

After starting the test execution, you will be redirected to the Results section where you'll get live video and all the results, logs and details in real-time.

Finding Elements in iframes with Selenium

Klaus — Tue, 06 Aug 2019 12:21:58 +0000

Anyone who is using Selenium has encountered a scenario where they have to deal with an iframe.

There is no automatic way of detecting that the element you're looking for is inside an iframe.

The error message only says 'Element not found'.

You're the one who's going to have to look in the Browser Console and figure out that your element is inside an iframe.

Let's create a test for the Stripe Payments Demo which has an iframe.

I'll also be making some comparisons between Selenium and Endtest:

An iframe (inline frame) places another HTML document in a frame.

You need to change the focus of Selenium from one HTML document to another.

In our case, the only element which is inside the iframe is the Card input.

I used Python:

driver.get("https://stripe-payments-demo.appspot.com")

nameElement = driver.find_element_by_name("name")
emailElement = driver.find_element_by_name("email")
addressElement = driver.find_element_by_name("address")
cityElement = driver.find_element_by_name("city")
stateElement = driver.find_element_by_name("state")
zipElement = driver.find_element_by_name("postal_code")
countryElement = driver.find_element_by_name("country")
iframeElement = driver.find_element_by_name("__privateStripeFrame5")
cardElement = driver.find_element_by_name("cardnumber)
submitButton = driver.find_element_by_css_selector("#payment-form > button")

nameElement.send_keys("Klaus Werner")
emailElement.send_keys("klaus.werner@example.com")
addressElement.send_keys("Random Street")
cityElement.send_keys("San Francisco")
stateElement.send_keys("CA")
zipElement.send_keys("94107")
countryElement.select_by_value("US")
driver.switch_to.frame(iframeElement)
cardElement.send_keys("4111 1111 1111 1111")
driver.switch_to.default_content()
submitButton.click()

Notice how I switched to the iframe before writing in the Card input?

And I also switched back to the main page after that.

It's a bit easier to deal with iframes if you're using Endtest:

Since you're planning to run that test multiple times, you should generate a random email address and store it in a variable.

You can even test that email with the Endtest Mailbox

Puppeteer vs Selenium

Klaus — Mon, 15 Jul 2019 19:55:39 +0000

Puppeteer and Selenium are both popular, powerful and widely used solutions for automating web applications.

But which one should YOU use?

The answer depends on your specific needs.

Choosing the wrong option could delay or worse, sabotage your automated testing project.

I'll share my own opinion at the end of this article.

Here are some PROS and CONS for both of them.

Puppeteer

PROS
• Faster than Selenium
• Easy to install
• Written and maintained by the Google Chrome devs

CONS
• Works only with Chrome
• The only supported language is Node.js

Selenium

PROS
• Works with most browsers
• Multi-language support
• Huge community of users

CONS
• Difficult to run on all browsers
• A bit slower than Puppeteer

To sum it up, Puppeteer is faster than Selenium, but it works only with Chrome, while Selenium works with Chrome, Firefox, Safari, Internet Explorer and Edge.

Now, for my opinion: both solutions are outdated and built with the narrow mindset of developers who refuse to see beyond their code.

It may sound lazy, but I believe that a solution for automated testing should be like a washing machine: it should give me enough flexibility to choose different inputs and settings, but it shouldn't make me pump the water with one hand and spin the drum with the other.

What both solutions are missing:

• Video Recording functionality
• Turnkey Machine Learning
• Integrated Email Testing option
• Screenshot Comparison feature
• Automatic Smart Waiting
• Structured results

Other issues with Selenium and Puppeteer:

• Difficult to upload files in a test
• Difficult to deal with iframes
• Difficult to integrate with your CI/CD system
• Difficult to configure Element Load Timeout

If you're looking for a better alternative, try Endtest.
It has Puppeteer's speed, it supports Selenium's browsers AND it has all the features that they're missing.

Testing Emails with Selenium

Klaus — Fri, 12 Jul 2019 12:47:46 +0000

Selenium is widely used, but it's a little known fact that you can use it to test anything built with HTML and CSS, including Chrome Extensions and Emails.

We'll create a simple test for the Register page from Swit and then we'll test the email that we receive.

I'll also be making some comparisons between Selenium and Endtest:

Selenium can only interact with HTML elements if they're in a browser.

This means that we'll have to open our email in a browser.

Luckily, anyone can use the Endtest Mailbox for free.

The way it works is similar to a disposable email service.
Simply send your email(s) to a username@endtest.io email address.

The username can be anything you choose.
For instance, you can choose something like jim32328@endtest.io.

You can access the Inbox for that email address on that page.

Just add the email parameter in the URL, like this:
https://endtest.io/mailbox?email=jim32328@endtest.io

Please note that the emails will be deleted after 2 hours.

But for now, let's get back the Register page from Swit:

driver.get("https://swit.io/register")

firstName = driver.find_element_by_id("firstName")
lastName = driver.find_element_by_id("lastName")
email = driver.find_element_by_id("id")
password = driver.find_element_by_id("password")
confirmPassword = driver.find_element_by_id("confirmPassword")
submitButton = driver.find_element_by_class_name("button--important")

firstName.send_keys("Klaus")
lastName.send_keys("Werner")
email.send_keys("klaus123@endtest.io")
password.send_keys("Password123")
confirmPassword.send_keys("Password123")
submitButton.click()

And here is the result:

Now, if we want to check that email, we have to go to:
https://endtest.io/mailbox?email=klaus123@endtest.io

And we'll be able to open our email:

We just have to write that part with Selenium:

driver.get("https://endtest.io/mailbox?email=klaus123@endtest.io")
email = driver.find_element_by_class_name("email_item")
email.click()

Since you're planning to run that test multiple times, you should generate a random email and store it in a variable and then append it to the Endtest Mailbox URL.

If you're looking for a better Selenium alternative, switch to Endtest.

A Practical Guide for Finding Elements with Selenium

Klaus — Wed, 12 Jun 2019 10:39:04 +0000

This article is for anyone who just started using Selenium and wants to know the best ways to find elements.

The key here is to find the most stable and reliable locator for each element.

Keep in mind that asking Selenium to locate an element is like telling someone from out of town how to find a certain coffee shop in your city.

We'll be using the Github Sign Up page as an example.

I'll also be making some comparisons between Selenium and Endtest:

We're going to use different locator types to find the Username input:

Find Element By ID
Find Element By Name
Find Element By Class Name
Find Element By XPath
Find Element By CSS Selector
Find Element By Link Text
Find Element By Partial Link Text
Find Element By Tag Name

1) Find Element By ID

Always the first choice.

In order to get the ID of your element, you just have to right click on your element and click on the Inspect option.

The structure of your element will be highlighted in the console:

It seems that our element has the following ID:

user_login

This means that your line of code will look like this:

username = driver.find_element_by_id("user_login")

Since an ID should be unique on a page, it's the most reliable locator type that you can use.

It's like having only one Starbucks in your city and telling your friends to meet you there, they can't miss.

2) Find Element By Name

Just as good as ID, but you won't encounter it as often as you'd expect.

Elements from forms usually have the Name attribute.

We can easily see that our element has the following Name:

user[login]

username = driver.find_element_by_name("user[login]")

3) Find Element By Class Name

Not so reliable, since a Class Name is usually shared by multiple elements.

We can easily see that our element has the following Class Name:

form-control

And if we take a closer look at the rest of the inputs from that form, we'll see that all of them have the form-control Class Name.

username = driver.find_element_by_class_name("form-control")

This means that the you won't be able to locate that Username input with the Class Name locator type, since Selenium will throw an error.

Endtest has a more elegant approach here than Selenium.
If you provide that Class Name, it will only give you a warning, telling you how many elements it found with that Class Name and that the first one will be used.

If Starbucks had a Class Name, it would probably be coffee-shop.
If you tell your friend Meet me at that coffee shop, they might not know which one you're talking about.

The most common mistake done by beginners is extracting all the Class Names instead of just one.

Let's take a look at this element:

A novice user might say that the element has the following Class Name:

HeaderMenu-link d-inline-block no-underline border border-gray-dark

But it actually has 5 different Class Names:

HeaderMenu-link
d-inline-block
no-underline
border
border-gray-dark

That's right, Class Names are separated by spaces.

Selenium does not have a validation for that, but Endtest does:

4) Find Element By XPath

You simply can't avoid having to use XPath for at least some elements.
It's not as bad as they say.

An XPath is like a route. There are a lot of routes that your friend can take to get to that Starbucks.

Usually, an XPath looks something like this:
/html/body/div[4]/main/div/div/div[1]/p

The fastest way to get the XPath is from the Chrome console:

In this case, we got the following XPath:

//*[@id="user_login"]

If you have a stable ID, you shouldn't bother to use XPath.

And if you don't have a stable ID, the XPath that we got is not reliable.

There are lots of web applications which are using dynamic IDs for some elements.

An element with a dynamic ID is like a coffee shop which is changing its name every day.

You know that the coffee shop was called iCoffee yesterday, but you have no idea what name is it going to have today.

Telling your friend to meet you at iCoffee will be confusing.

That's when we need to write our own XPath.

Find out what are the stable attributes and characteristics of that element.

Going back to the example with the coffee shop that has a different name.

What is something that doesn't change about it?

Perhaps the location and the fact that it's a coffee shop.

This means that you can tell your friend from out of town to meet you at the coffee shop from the West Shopping Mall.

Let's take a look at our element and get the XPath of its parent:

This is the XPath that we got for its parent:

//*[@id="signup-form"]/auto-check[1]/dl/dd

This is practically the address of the West Shopping Mall in our example.

Now all we have to do add some details at the end.

Our Username element is an input and it has the form-control Class Name.

This means that we need to append the following to the parent:

/input[@class="form-control"]

And that part translates to:
Look in that parent for an input which has the form-control Class Name.

And the final XPath for our Username element will look like this:

//*[@id="signup-form"]/auto-check[1]/dl/dd/input[@class="form-control"]

Always verify your XPath in the Chrome console by hitting Ctrl + F and searching for it, you should see your element highlighted like this:

Writing your own XPaths isn't so scary. You will encounter situations where your element might not have an ID, but it will have a certain reliable attribute which makes it unique.

In that case, your XPath will look like this:

//*[@attribute = "attribute_value"]

You can also write an XPath which locates the element by using only part of the value of the attribute:

//*[contains(@attribute, "part_of_attribute_value")]

For example, our Username element has the following attributes:

aria-describedby="description_2822cb3d798c"
name = "user[login]"
autocapitalize = "off"
autofocus = "autofocus"
required = "required"
class = "form-control"
type = "text"
id = "user_login"
autocomplete = "off"
spellcheck = "false"

If we want to use the aria-describedby attribute, this will be the XPath:

//*[@aria-describedby = "description_2822cb3d798c"]

If you're using Endtest instead of Selenium, their recorder will know how to automatically extract these custom XPaths.

5) Find Element By CSS Selector

The CSS Selector locator type is similar to XPath.

Some people actually claim that it's faster.

Usually, a CSS Selector looks like this:
body > div.application-main > main > div > div

And we extract it in a similar way:

In this case, we got the following CSS Selector:

#user_login

If you're familiar with CSS, you'll know that # stands for ID.

The similarities with XPath don't stop here.

If you have a stable ID, you shouldn't bother to use CSS Selector.

And if you don't have a stable ID, the CSS Selector that we got is not reliable.

The solution?

To write our own custom CSS Selector.

Let's start by extracting the CSS Selector for the parent of the Username element:

This is what we get:

#signup-form > auto-check:nth-child(4) > dl > dd

Now, just like we did for XPath, we need add some details at the end.

In case you forgot, our Username element is an input and it has the form-control Class Name.

This means that we need to append the following to the parent:

> input.form-control

And that part translates to:
Look in that parent for an input which has the form-control Class Name.

If you're familiar with CSS, the dot stands for Class Name.

And the final CSS Selector for our Username element will look like this:

#signup-form > auto-check:nth-child(4) > dl > dd > input.form-control

It's not mandatory to add both the element type and the Class Name.

You can just use one of them:

#signup-form > auto-check:nth-child(4) > dl > dd > input

#signup-form > auto-check:nth-child(4) > dl > dd > .form-control

Again, if you're using Endtest instead of Selenium, their recorder will know how to automatically extract these custom CSS Selectors.

6) Find Element By Link Text

The Link Text locator type only works for links.

Your element is a Link if it has the following format:

The a stands for Anchor.

Since our Username element is an input and not a link, we won't be able to locate it by using Link Text.

It's worth remembering that the Link Text is only the text between the tags.

In the case of the link from the screenshot, the Link Text is Enterprise.

Our Selenium code would look like this:

enterprise_link = driver.find_element_by_link_text("Enterprise")

7) Find Element By Partial Link Text

As the name suggests, it's exactly like Link Text, but with the difference that you only need to add part of the Link Text.

And this would be our Selenium code:

enterprise_link = driver.find_element_by_partial_link_text("Enterp")

8) Find Element By Tag Name

As we have seen from the previous examples, an element always has a tag.

You can use the Tag Name locator type if that's the only unique characteristic of the element that you can grab on to.

Realistically speaking, I don't think you'll ever use this one.

Endtest has an extra locator type, Text Inside, similar to Partial Link Text, but it works for all types of elements.

Even if your locators are reliable, you will encounter situations where your web application goes through a revamping and you'll consume time on keeping your tests in sync with your web applications.

One option to avoid this situation is to use Machine Learning:

Can you believe I made a test that can play Chess?

Klaus — Fri, 31 May 2019 12:52:26 +0000

I have been experimenting a lot with the Endtest platform lately, since I'm helping them out with my testing expertise.

Trying to find extreme scenarios that cannot be automated, I ended up trying to automate some tests for a Chess game.

Needless to say, it went pretty well.

As you can see, my test played a decent game.

The assertions are checking if my movements were registered correctly.

What made it easy is the fact that all the pieces and squares are actual HTML elements.

If I was dealing with a HTML5 Canvas element, I would have needed to use the Click with Offset action.

I talked to them and sent them the video, ended up being posted on their YouTube channel.

Can you think of any site or scenario that is impossible to automate?

Would love to get some fresh ideas.

10 Things You Didn't Know About Selenium

Klaus — Wed, 29 May 2019 13:51:52 +0000

1) You can use Selenium to test Chrome Extensions.

Those extensions are built with HTML, CSS and JavaScript, you just have to learn a few tricks in order to access the extension in the main viewport.
I wrote a detailed tutorial about it a few months ago.

You can also test Chrome Extensions with Endtest.

2) Taking a screenshot of an element instead of the entire page.

This one is tricky.
By default, Selenium only allows you to take a screenshot of the entire viewport.
You need to extract the coordinates and the size of your element and use them to crop it from a full page screenshot.

I used Pillow for the cropping part. 🤓

driver.save_screenshot('/Users/Klaus/Test/fullPageScreenshot.png')
myElement = driver.find_element_by_id("register")
location = myElement.location
left = int(location['x'])
top = int(location['y'])
right = int(location['x']) + int(size['width'])
bottom = int(location['y']) + int(size['height'])
fullPageScreenshot = Image.open('/Users/Klaus/Test/fullPageScreenshot.png')
elementScreenshot = fullPageScreenshot.crop((left, top, right, bottom))
elementScreenshot.save('/Users/Klaus/Test/elementScreenshot.png')

3) Uploading a file in a test.

A cool trick I learned from my friends at Endtest.

When you upload a file on a site, a native window from the Operating System opens which allows you to select the file.

After you select the file from that native window, the local path of the file is written in the input type="file" element.

The problem here is that Selenium cannot interact with that native window.
This means that it cannot select the file.

That's why we need to skip that part and just write the local path for that file in the input type="file" element.

fileInput = driver.find_element_by_id("upload_file")
fileInput.send_keys('/Users/Klaus/Test/Instructions.pdf')

Of course, that input type="file" element might be hidden and you would need to unhide with some JavaScript:

jsCode = 'document.getElementByid("#upload_file").style.display="block"'
driver.execute_script(jsCode)

4) Clicking on a certain point inside an element.

By default, Selenium clicks in the center of an element.

You might need more precision when dealing with a HTML5 Canvas element.

We can use the ActionChains from Selenium to move to a certain point inside the element and perform a click there.

canvas = driver.find_element_by_id("drawing_board")
chain = ActionChains(driver).move_to_element_with_offset(canvas, X, Y)
chain.click()
chain.perform()

That's right, you can use Selenium to play Chess online. ♟️

5) Reading the Page Source.

If your site is using tags, you can easily check those with Selenium.

pageSource = driver.page_source

As you know, tags are hidden and can only be seen in the page source.

6) Performing a Drag and Drop.

Once again, we're using the ActionChains from Selenium.

target = driver.find_element_by_id('ball')
destination = driver.find_element_by_id('goal')
ActionChains(driver).drag_and_drop(target, destination).perform()

Did we just score a goal with Selenium? ⚽️😱

7) Simulate a webcam and a microphone.

Useful if you're running your tests on a machine from a cloud.
Available only with the chromedriver.

options = webdriver.ChromeOptions()
options.add_argument("--use-fake-ui-for-media-stream")
options.add_argument("--use-fake-device-for-media-stream")
driver = webdriver.Chrome(executable_path=chromedriver, chrome_options=options)

8) Using HTTP Basic Authentication.

That's the native window which is asking for credentials to access a site.

You can't write text in those inputs with the traditional send_keys method, because that window is outside the viewport.

The solution?

Just add your username and password directly in the URL.

driver.get('http://username:password@example.com')

9. Using Machine Learning to fix your tests.

10. Using any attribute to locate an element.

Selenium lets you locate an element by using one of the following:
• ID
• Name
• Class Name
• Link Text
• Partial Link Text
• Tag Name
• CSS Selector
• XPath

But what happens when you have an element like this one?

You need to get creative and write an XPath based on an attribute, like this:

//*[@attribute = "attribute_value"]

For our element, this results in the following:

//*[@type = "submit"]

You can also write an XPath which locates the element by using only part of the value of the attribute:

//*[contains(@attribute, "part_of_attribute_value")]

For our element, this results in the following:

//*[contains(@type, "sub")]