What's New in Selenium?

 It's hard to believe, but Selenium is on the point of turn 11 years old. Selenium was originally developed in 2004 by Jason Huggins at ThoughtWorks as a tool to assist out with some internal projects. lots have changed since then, and not just in Selenium. This new automation toolset made something that was previously very difficult and fragile — automation of tests during a browser — just a touch easier to make and plenty more useful. These changes and developments in Selenium also had the side effect of making a community of open source and commercial tools. Selenium is now becoming the actual browser testing tool. you'll be able to find out how to urge started with Selenium here.

Native Events And FireFox

Your clicks just got an entire lot clickier for tests running in FireFox. The team recently added support for native events within the latest few versions (FireFox 24, 31, 32, and 33). what's a native event and what's that have to be compelled to do with me, you ask? Native events are the signals your browser sends to the pc after you are working — mouse clicks, button presses on the keyboard, and scrolling. Normally these items come from an individual making the browser do useful things, but with automation, it is a little different. When Selenium first came along, they were sending what we predict as Generic Events; events that employ across different browsers. Generic Events were useful because they got browser automation moving along, but they were a hack. Generic Events were simulated browser events that would be used across any browser, but sometimes there have been problems.

Have you ever had those moments where something would add your automated test, but not within the browser, or vice versa? it had been probably associated with how the events were being sent.

As of version 2.44, after you do something like window. click('button') in FireFox, you're actually causing the browser to fireplace a true click event. FireFox automation is more realistic than it's ever been.

More Support for Internet Explorer

If you're using the newest version of Internet Explorer 11, you're in luck. Microsoft developed a collection of WebDriver bindings specifically for Internet Explorer aptly named InternetExplorerDriver. This implementation of WebDriver pairs up with a server called IEDriverServer.exe to make your testing environment. the matter with this was that InternetExplorerDriver was a separate implementation completely and couldn't possibly match the WebDriver feature set that has been growing over the past 10 years. which means that if you needed some specific functionality for your test, you'd probably find yourself using two different frameworks to induce the work done.

Now that there's official support for Internet Explorer (check out the .net bindings), not only are you able to concentrate on one single tool but if there's a missing feature you would like you'll fall back on WebDriver.

This is a much bigger deal than it sounds, we'll dive into the main points about why a bit later.

Automated Visual Testing

Visual testing — staring at pages, and noticing changes between builds — has traditionally been very, very hard. to try to do this some years ago you'd need to navigate to each page in your app, or a minimum of as many as you may remember, click the button or run the script for your visual tool to try to some recording of CSS and DOM elements. This 'recording' is your benchmark, what every other version of your app is going to be compared to till you update the recording.

Now, there are some tools that may benefit from the Selenium scripts that are already testing your software. rather than making a separate experience on each screen in your software, these tools follow together with your scripts and take a digital snapshot for every page that your script lands on. once you run your scripts again, each existing snapshot is compared to what you'd see if you were watching the web site yourself. Visual test automation is now almost a hands-off matter.

In The Works For Selenium

Some of the foremost exciting things to come back in are already in motion. The Selenium team has been working for a few times now to induce a political candidate WebDriver specification published through the W3C. The draft is currently in a 'working draft' state and hasn't been updated since March 2013. This has been lots of labor for the hardworking people on the Selenium project and can have an enormous impact on WebDriver users and also on the broader testing community.

An official WebDriver specification implies that browser vendors are going to be ready to create and maintain browser-specific implementations of WebDriver. Microsoft has already begun using the new spec while it is not official and built a web Explorer specific implementation of WebDriver that you just can use in IE 11 and newer. Blackberry and Safari are following suit. What this suggests to you, the user of the WebDriver framework, is that you just can now rest a touch easier. Browser updates are going to be more likely to continue working with the version of WebDriver you're using, and if they are doing break something will likely include a WebDriver update.

For Selenium, this suggests they're taking another step toward becoming the default browser level testing framework. that's why you should learn the Selenium Testing tool and take Selenium Training in Pune.