Technical on Selenium

BELLATRIX Test Automation Framework for C# and JAVA

Wed, 16 Nov 2022 00:00:00 +0000

Over the last decade, a large ecosystem of Open Source projects has sprouted up around Selenium. Selenium is often used for automating web applications for testing purposes, but it does not include a testing framework. Nowadays, Selenium Ecosystem initiatives try to give popularity to popular open-source test automation frameworks maintained by people outside of the core Selenium maintainers. One of these frameworks is BELLATRIX, invented by Anton Angelov. It has two versions - C# and Java. A testing framework is an abstraction in which common code provides generic functionality (which can be selectively overridden) for testing different aspects of our applications- UI, API, security, performance, and many others.

Observability in Selenium 4

Mon, 26 Apr 2021 00:00:00 +0000

Diagnosing problems when the Selenium server isn’t working has never been easy. With Selenium 4, we have integrated OpenTelemetry to help you troubleshoot issues, optimize performance, and provide visibility into the system. By making the Selenium server observable, we are putting more power into your hands.

Need for Observability

Selenium server enables distributed testing. Instead of running the browsers for tests locally, the tests use a remote browser driver that points to a server. The server makes “smart” decisions to run tests on different remote servers. Every such remote server is capable of hosting different types of browsers and browser versions.

Browser Testing and Tools WG Meeting @ TPAC 2020

Thu, 29 Oct 2020 00:00:00 +0000

It’s that time of the year where working groups from the W3C meet up to discuss the various standards that are being worked on.

Within the Browser Testing and Tools Working Group, there are 2 different standards.

We have:

The first is what is commonly supported by the Selenium Project and has support from Apple, Mozilla, Microsoft, and Google in their browsers. It is also supported by various Selenium in the cloud providers like Sauce Labs and BrowserStack.

How to delete your master branch

Thu, 27 Aug 2020 00:00:00 +0000

At the Selenium project we practice trunk based development, in which trunk is the usual name of the default git branch of the repository. However, when the project was moved to GitHub, the repository followed the traditional use of master as a name for the default git branch.

With the intention of making the Selenium project an even more inclusive place where everyone is welcome, a decision was made to use trunk as the default git branch and, after the switch, delete the master branch. This change created a few challenges. This blog post will point out a few things you should watch out if you want to make the same change in your GitHub repository.

Moving to Trunk

Wed, 01 Jul 2020 00:00:00 +0000

Since the project started we have been following trunk based development. This was a very natural fit when we were using SVN over a decade ago on Google Code.

As Google Code shut down we moved to GitHub and the git model of doing things. We moved there mostly due to the gravity that GitHub had created in Open Source projects.

This meant that we followed the standard use of master as our trunk to work off. Now that GitHub, and services that use GitHub, have improved support for non-master branches as default we are moving our default branch to trunk. It describes how we, as a project, work and is a more inclusive term.

Source Control

Mon, 14 Jan 2013 00:00:00 +0000

This short technical note is to announce that the Selenium project is now using git on Google Code in place of subversion.

The move has been a long time in the making, and it’s largely thanks to the efforts of Kristian Rosenvold that we’ve been able to do the migration and retain the project history. The project owes him a huge thank you! We’re in the process of migrating the last bits and pieces (none of which are user facing), so there may be some last minute turbulence as we settle everything down.

Going Atomic: How

Sun, 05 Sep 2010 00:00:00 +0000

This is the second of my technical posts. Again, if you’re interested in the internal workings of Selenium 2, then please skip straight to something else. If you’re interested in how and why we made some of the technical decisions on the project, keep reading….

We left our intrepid heroes in a tight spot: they’d decided to write a shared library of code, to be used by the various webdriver implementations and selenium core, but the requirements for doing this seemed to be at odds with it actually happening.

Going Atomic: Why?

Mon, 16 Aug 2010 00:00:00 +0000

This is the first in a series of technical posts by me about the internals of Selenium WebDriver. If you’re not interested in technical nitty-gritty, then feel free to step away now.

Still here? Excellent.

Let’s take a step back to just before the Selenium and WebDriver projects merged. There were, very obviously, two separate codebases. Looking closer and with a slightly different perspective, there were more than this. We used the test suites for webdriver to define the behaviour for multiple, largely independent, driver codebases. The IE driver was written in C, the HtmlUnit driver in Java and the Firefox driver is largely Javascript, and so on.

How to use Selenium 2 with Maven

Fri, 30 Jul 2010 00:00:00 +0000

There are several ways to use Selenium 2:

If you don’t have Selenium 1.x legacy code, you might want to directly use on of the new WebDriver implemenations like ChromeDriver, HtmlUnitDriver, FirefoxDriver, or InternetExplorerDriver which provide a nice, small and easy to learn API.
If you have Selenium 1.x legacy code, you can still use the well known DefaultSelenium class or the new WebDriverBackedSelenium, which extends DefaultSelenium but uses one of the WebDriver implementations internally.

Whichever option you prefer, if you have want to use Maven, all you need to do is add the following dependency to your pom.xml: