We have recently moved to Selenium Web Driver. We have loads of tests written in selenium Rc which are now working fine using webdriverbackedselenium API. Now I am planning to move to web driver. Can you please guide what the is best approach to shift. Either completely move the code to use web driver but it requires a lot of effort. Or use both. It means I need to keep wrapping and unwrapping the driver. Totally confused about the layout of structure. Please guide.
It really depends on how your old tests were organized. If you used Page Object Pattern in your old tests migration to WebDriver should not be so difficult. Just create base class for all your page model classes and put in it all the logic that you need to initialize your page instance using Page factory. After that you can rewrite old page classes one by one preserving old interface in order to reduce amount of changes in the tests.
Related
I am new to Selenium and have spent about a week using IDE. So far, so good. However, some other parts of our application involve heavy drag-n-drop capabilities, and I'm not so sure about that...which brings me to my question...what type of specific things can WebDriver do that the IDE cannot do? I read the Selenium front page, and know that WebDriver can make more "robust" tests, but I'm not entirely clear what robust means in this context? Longer? More capabilities?
What I'm looking for is what type of particular tests could be run with WebDriver that couldn't be run in the IDE? And are any of them related to drag-n-drop? This will inform my decision about whether to keep on using the IDE or to switch over. I think it's better to use something from the beginning than to create a lot of tests and then switch over.
Thanks much in advance.
You can use the full features of your chosen language. For example, using the IDE you are stuck to using the IDE's API, however if you choose to use the WebDriver explicitly you can combine it with C# and use C#'s full features (such as LINQ).
A few of the IDE commands are not directly converted with the WebDriver.
You can integrate a pure WebDriver test into a CI (Continuous Integration) server.
It is not limited to just Firefox, whereas the IDE is (since the IDE is only available in Firefox).
You can improve and extend Selenium more easily. For example using Extension methods and inheritance. (For instance, extending Selenium so that whenever it cannot find an element, it takes a screenshot of the page)
It will be more robust, as the IDE will not always give you the most reliable way of finding an element. For instance, if the element you require is nested within a table, the XPath that the IDE will give you will infer directly to specific table rows and cells.
For instance something like this:
//table[1]/tr[1]/td[2]/table[1]/tr[1]/td[3]/a[1]/b
Is not the most reliable XPath in the world. Those without any knowledge of XPath or automated testing or how Selenium works, will stick with that and then waste hours figuring out why this XPath query fails. Others will change it, and just use the XPath as a base query.
The IDE should usually be used for those who don't have much programming knowledge (e.g some testers), if you want your developers and/or the test developer's to use Selenium, go directly with the WebDriver. It will feel more like programming with a fully-fledged language instead of scripting (after all, the scripts that the IDE generates are purely HTML files). The idea is generally for those who don't have much programming knowledge to simply hit 'play' and let Selenium do the work.
Drag-and-drop are applicable within the IDE and WebDriver.
Most of the development in Selenium (it seems) goes into extending the WebDriver code, the IDE may be left behind in some new features.
Using WebDriver directly, you can also use the full features of a unit testing framework (usually NUnit with C# or Junit/TestNG for Java). This allows things like repeating tests for each browser (i.e repeating tests in Chrome, Firefox and IE) or defining certain logic before and after tests (i.e adding user memberships, creating users, setting up other test data).
Fellow developers might be more inclined to help out if it is using a programming language as opposed to a scripting language (ie WebDriver is programmed in a programming language, the IDE scripts are just HTML files). Putting it in your solution and having it as part of the nightly build process helps to ensure developers help out in your tests progression.
Thinking about it, another example is a bug is fixed but introduces a new bug which causes your test to fail. Who's responsibility is it to fix the test? You or them? Having it use WebDriver directly, they can just look up the source code to Selenium and figure out the API usage themselves. With the IDE, it is literally a HTML file that calls some javascipt. Not much documentation on it.
To sum up: if you don't have much programming experience, either learn a language and use WebDriver with it directly, or just stick with the IDE. Either will do the job.
IDE cannot be used for serious automation. I would sussgest learn the API and use it with Java/C#/Python. It will help you churn out some good automation and will payback really well.
You can always use the IDE to learn how the code is generated.
I am new to selenium web testing. Could you tell me how to learn it step by step, and what the technologies are that I need to study?
I suggest you download Selenium IDE or Se Builder, which are user interfaces for recording Selenium tests in-browser. Both let you record and then export tests to a bunch of different languages.
One important thing to note is that there's two Seleniums: original Selenium 1, where tests are comprised of a list of steps to execute in order, and Selenium 2 / Webdriver, which is an API for programming tests.
(Full disclosure: I'm the main developer on Se Builder, so I'm totally biased towards it. I do think it's probably less intimidating for a newcomer, but Selenium IDE is as of time of writing the more established and standard IDE. :) )
UPDATED: Additional resources listed below
The record and playback tools Zarkonnen called out are good starts. You also need to understand the fundamentals of Selenium itself. There's good information on writing tests in code on Selenium HQ's documentation pages.
Three things I think important to get correct from the start:
Learn about locators on pages, learn how to store them in one location (read up on the Page Object Pattern and be careful about record/playback tools which may not help you in that approach)
Learn how to deal with dynamic content (AJAX) with implicit and explicit waits
Learn about modular tests. Write small, reusable components.
If you're working in Ruby then I'd really recommend having a look at Cheezy's page_object gem.
Also, have a look at the various intro pages on the Google WebDriver project page.
Update: You should also consider having a look at Dave Haeffner's Elemental Selenium and his Selenium Guidebook. Both are great resources for real-world stuff people struggle with, not facile, shallow examples.
Hi I want differences between architectures of selenium RC and webDriver.
I read lot of functional differences but did not find anything for architecture differences.
If anyone can send/post links of differences that will really appriciate.
Thanks in advance
The difference is quite substantial.
Selenium RC works only using JavaScript for its every command. That means that everything you write is eventually translated into Javascript and run in the browser. This approach has several pros and cons - it should work the same way in every browser, but is limited to "same origin policy" and to JavaScript limitations.
http://seleniumhq.org/docs/05_selenium_rc.html#how-selenium-rc-works
WebDriver actually uses each browser's own and native API's to work with them. That means that it sometimes needs direct help from browser development team, sometimes fails on a new browser version release, sometimes behaves slightly differently on different browsers (but hey, on IE, js was also not the most reliable thing), but is a much stronger tool overall. It should be faster, it should allow for much more complex work without any js limitations.
http://seleniumhq.org/docs/03_webdriver.html#how-does-webdriver-drive-the-browser-compared-to-selenium-rc
Note that while Selenium RC has been oficially deprecated, the WebDriver is now being developed rapidly and it still suffers from several child-illnesses and is not in its full strength. That said, using WebDriver, you can do anything Selenium RC can do. And sometimes more. With an occasional minor bug.
here you can Selenium Webdriver Architecture
http://qeworks.com/selenium-webdriver-architecture/
you can also find diff. between RC and webdriver below
http://qeworks.com/difference-between-selenium-rc-and-selenium-webdriver/
Though there are many advantages of Page Project Model, some of them worth mentioning are :
Simple and clear page classes with sensible method names.
You can actually give the customize names to you methods. Like above so that you need not to keep anything in mind.
Just looking into the method name gives you all idea about the capabilities of the method.
Makes tests more readable. In comparison to above commands of selenium , where in you need to add all the commands in the tests scripts . in page object model you need to put method names. The methods which you have created according to your understanding of application so these methods name are more readable and easy to understand.
Stay [DRY]
Page object model believes in the principle of Do not repeat yourself.
Good support of tests, because everything is stored in one place.
Easy creation of new tests. In fact, tests can be created by a person not knowing the features of automation tools.
As I have actually implemented it in my project so definitely there are some flaws:
All locators should be kept in page class file.
And this abstraction leads to some chaos with in the Page Class file.
So you need to implement something like key word driven on top of Page Object Model so as to fully take the advantages.
Has anyone done some extensive automation with Selenium and a Dojo-heavy web app? I'm looking for any issues or problem that you might have run into or issues related directly to the combination of Selenium and Dojo.
I've used Selenium extensively with a bunch of different web apps, including a few on Dojo. You should be fine. One practice I would recommend is to make sure all the components you'll be testing (both UI controls you'll be driving, as well as text components you'll be reading for testing) have ID tags set. Selenium has a bunch of elegant selectors to get at the elements you need, but selection by ID is still the best. The other methods can be more brittle.
I've had some challenging experiences with Selenium RC not being as compatible with my code as Selenium IDE, to the point that I stopped using Selenium RC. And in case you are not super familiar with Selenium, you should be aware that it doesn't natively support some (IMO) pretty fundamental features like flow control and includes; but there are user extensions to the framework that allow this. I'd also recommend taking a look at Watir which I now generally prefer over Selenium because it exposes the full power/flexibility of a first class language (Ruby).
I'm working on a Dojo-heavy app right now, and am making a number of tests with Selenium IDE. I've ran into a few issues with certain Dojo elements, such as drop down menus and tabbed components. I've learned to appreciate XPath, and have been experimenting with how clickAt and waitForElementPosition commands, which seem to help accommodate for some of Dojo's features.
Dojo specifics - very brief
The Dojo itself differs in some approaches from other heavy-DOM and extensively impressive frameworks (like ExtJS, jQuery, YUI).
The general Dojo specific it workaround the limitations by using Flash (YUI does as well) or Silverlight.
Here is a couple scenarious when Dojo can use Fash:
the browser is not HTML5 and javascript need local storage. Then Dojo will use "Flash Cookie" Flash Local Shared Objects (package dojox.storage)
need support of cross domain https calls.
The general tricks that can turn your testing into something difficult:
browser messages, like "do you wish to allow this site..."
nested frames can make the selection of the node difficult
javascript timeout/intervals they might work with different speed in Selenium then in real browser. Yes they can.
The biggest issue I encountered was the fact that dojo menus, and pop-up UI elements in general, are absolutely positioned as children of the body element and are not children of the element that creates them.
This can impact how you write Selenium CSS Selector and, in my case, made it a bit more challenging to automatically crop a screenshot that includes a menu and its dropdown.
Selenium should be fine with dojo because it's rendered in Firefox and not on it's own. Just make sure dojo is available when testing ( i.e. don't connect to google's cdn if your test environment doesn't have an internet connection ). But that's a problem you'd have with any external resource
I have no experience, but did see http://www.ibm.com/developerworks/opensource/library/os-webautoselenium/index.html discussing how to use Selenium with dojo
If you need to test in an SSL environment and you use Selenium RC's trustAllSslCertificates + proxy, you must make sure all of your JS files are hosted on the same domain. I've seen problems recently with using CDNs to load JS and image files when testing under recent Firefox versions and selenium rc
Selenium 2 has been in beta phase for last few months. I would like to know learning’s if any of our us have analyzed/migrated from selenium 1 to selenium 2
How much was the effort involved in terms of Changes# to accomodates 2 features. Methods/API changes#
How much was perf improvements in terms of run time of tests in Selenium 2
Any best practices/learning shared would be useful
Going through the transition myself. If you had Selenium 1 experience, Selenium 2 feels quite different actually. Here is my Selenium 2 pros/cons vs. Selenium 1 I see so far (I use Python so some of them are Python specific):
Pros:
Much faster.
No need to run a separate server.
Gone are wait_for_page_to_load(), wait_for_element_present(), etc. All element interactions, clicks, etc. are blocking now, which is good. The only problem is with asynchronously loaded content (Ajax) though, see Con bellow.
Cons:
Loading/waiting for asynchronous content which used to be "free" with wait_for_page_to_load() requires coding now. These are the solutions I found so far:
use PageFactory/AjaxElementLocatorFactory like explained here, unfortunately I couldn't find the equivalent for Python.
use webdriver.implicitly_wait(N), this seems to be doing the trick with Python but using that seems to cause my script to miss changing elements which it used to detect before.
don't do sleep(T), loop until element appears, etc, that defeats the purpose of the whole thing (and makes wait_for_page_to_load look beautiful)...
The whole thing still feels a bit raw. Different drivers and bindings seem to miss different functionality. Not to say you can't use it but be ready to find 'alternate solutions' for certain problems.
The documentation is a bit dubious (related to the prev. point I guess). Especially for Python. Be ready to read code and experiment a lot (which luckily is easy with Python). Most of the 'tutorials' you'll find on the web (again, esp. Python, Java seems to be much better covered) are just to get you started with the plainest of web applications.
No PHP bindings, not a big one I prefer Python but our original suite was PHP so I noticed.
SeleniumIDE seems to be useless with Selenium 2.
Other differences:
The page elements you are accessing have to be 'visible' on the page at the moment when you ask selenium to find them. For example if you have a menu (containing a list of links) which opens when you hover your mouse over, you have to make sure it is open/visible before you click on a link inside (which wasn't the case in Selenium 1). This has it's uses since you'd be testing what an user would see on the page but requires the extra code. I found two solutions:
run a Javascript which would open your menu, in my case driver.execute_script("document.getElementById('dashboard_menu_navigation').show()") then click the menu item driver.find_element_by_link_text('Orders').click()
use the Mouse / Keyboard classes to simulate actual interaction, this seems to be broken in the Python bindings though (see Cons above):
Example (which throws 'WebElement' object has no attribute 'mouse_move_to' today):
element=driver.find_element_by_id('mn_dashboard')
mouse=Mouse()
mouse.move_to(element)
The Cons list seems longer but that is mostly if you are coming from Selenium 1. I do prefer the lightness and speed of Selenium 2 and despite the early code (using 2.0b4 at the time of writing) the whole thing is quite usable.
Hope to save someone some time...
Moving from Selenium 1 to Selenium 2 is as simple moving from
Selenium selenium = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.example.com");
selenium.open("/");
to
Webdriver driver = new FirefoxDriver();
Selenium selenium = new WebDriverBackedSelenium(driver, "http://www.example.com");
selenium.open("/");
Since Selenium 2 is more tightly bound to the browser you will see huge difference. I have seen tests running at least 2x faster but in some cases I have seen it running 4x faster.
All the same best practises that you learnt during Selenium will be the translated across
Slides that might help too are posted here:
http://www.slideshare.net/rogerjhu1/lessons-learned-migrating-tests-to-selenium-v2
You can use WebDriverBackedSelenium class to convert WebDriver interface into Selenium interface:
Selenium selenium = new WebDriverBackedSelenium(webDriver, baseUrl);
or you can use the method getUnderlyingWebDriver() to convert Selenium interface into WebDriver interface:
WebDriver webDriver = ((WebDriverBackedSelenium)selenium).getUnderlyingWebDriver();
I posted slides of one of my recent presentation on how to get started with Selenium 2 here:
http://www.slideshare.net/sebarmeli/getting-started-with-selenium-2
One of the best practices in Selenium 2 is the PageObject pattern.
If you are using Java and Maven, you may want to check out this Archetype plugin (that also gives you a first taste of the PageObject pattern):
https://github.com/sebarmeli/Selenium2-Java-QuickStart-Archetype