Does anyone have any resources on usage of selenium selectors (specifically javascript)
Ideally there'd be a chrome plugin that allows you to inspect an element and gives you the (all) method(s) of selecting it.
The IDE for firefox looks nice: http://docs.seleniumhq.org/projects/ide/
Just wondering if there are's anyway to simplify this annoying task.
You can (but highly discouraged) use Firebug + Firepath to generate CSS selectors/XPaths.
For complex web applications, there is no way you can get maintainable locators from those generators.
Auto-generated selectors are purely rubbish in terms of maintenance. Machines can't determine what is the most efficient way to locate, unless developers construct some certain algorithms depending on the structure of DOM. But I believe that is much hard than learning XPath or CSS selector.
My suggestion would be every Selenium developers should learn XPath and CSS selectors properly. Firebug + Firepath would be a good tool to evaluate and validate the locators, but please compose them from scratch.
For example, this is what a basic XPath generator would give you:
.//*[#id='page']/div/div/div/div/div/div/div/div/ul[1]/li[1]/a
This is what a "smart" generator might do (which simplifies XPath by certain pre-defined rules, but may still cause trouble):
.//*[#id='page']//a
But this what a experienced human developer would do:
.//*[#id='page']//div[starts-with(#class, 'header-')]//a[contains(#class, '/blog')]
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
I have been using Selenium a lot lately (testing an ExtJs app) and while in many ways it is wonderful, there are three things that cause me a lot of grief:
Inability to directly click on elements other than buttons. This has led me to write a bunch of Robot code to move the mouse around. That works but is a bit fragile, plus if you touch your mouse while a test is running, you are screwed. I tried the Selenium forums to see if there was a better way, and got nowhere. I think (but am not sure) that this is a fundamental limitation of Selenium's JS injection technique.
Inability in many cases to control what the 'id' attribute get sets to. This happens inside ExtJs and some elements let you set it, some don't, and some do but the attribute ends up where you don't expect it. You end up having to use XPath in some cases. Using XPath with ExtJs is kind of horrible as ExtJs creates massive levels of nested DIV's. You can also sometimes use CSS locators (which are also inconsistently controllable in ExtJs). (BTW, this is obviously not a Selenium problem per se).
The time that Selenium takes to fire up FF is too long... way longer than a normal human FF startup, about 2 seconds per test, which translates into tests that last several minutes, way too long.
I briefly looked at Watij, BadBoy and a couple of other web functional testing apps but none of them looked anywhere near as good as Selenium. (The way Selenium tests can be written in Java and run through jUnit is really, really sweet). There are also a few commercial alternatives but they are beyond my budget and there is no assurance that they would work any better anyway.
Any thoughts or suggestions appreciated.
About 3:
Selenium copies at startup the firefox profile to a temporary folder. If you don't specify a custom profile, Selenium propably uses the default profile which propably is bloated with addons you don't need for the test. Startup Firefox with '-p' and create a new profile for Selenium and copy it to a location you can point selenium to. This should speed up the test a bit.
Update:
Firefox Profile location / Windows: %APPDATA%\Mozilla\Firefox\Profiles
My thoughts:
There are some cases that click isn't enough, but you certainly shouldn't be limited to buttons. You might want to experiment further with your locators.
Why do you need to set the id attribute of elements? I have experience with testing ExtJS applications, and the problem is usually locating elements that have dynamically set ids. In my opinion this is an issue with ExtJS and not Selenium. Using smart XPath techniques using contains, starts-with, and substring can make your locators much more reliable. CSS locators are also often helpful as you mentioned.
As amarsuperstar says, you don't need to start Firefox before every test. If you do, you might want to consider using the browserSessionReuse command to speed up launching the browser. Alternatively you can use Selenium Grid to run tests in parallel.
Finally, it's well worth looking into the WebDriver API that will be in the soon to be released alpha of Selenium 2. In my experience Firefox launch times are reduced, and commands such as click are much improved.
I am not sure about the first two points, but as for the third, I don't think you need to start the browser for every test. You can use the Seleium server (a jar in the selenium directory somewhere) then point your tests to that e.g. localhost:6554 and that will only open the browser once.
With that you can have the steps in your script to start server -> run all test -> terminate server and you will only have one browser session across your tests.
My experiences (hopefully useful ;)
I've never had this problem, even with ExtJS. I have not used it with ExtJS 3.x, though. Is it possible that you are experiencing some thing as a result of your environment rather than Selenium?
UPDATE: As Dave Hunt reminded me, sometimes I've had to use mousedown/mouseup actions in lieu of "click"
I've found many clever ways to navigate using CSS locators (selenium supports most of CSS 3). In addition, you can use xpath like xpath=id('myid')//div['#class='foo'] (the ID part is crucial).
I've also never experienced this. Perhaps you can give some details about your environment?
Thanks for all the answers guys, I really appreciate it. I spent all day yesterday on this stuff and I wanted to add a couple of observations:
The way ExtJS lays stuff out can really make it hard to locate elements. For example, quite often the 'id' that you specified appears on an element that is 2-3-4 items in the DOM above the one you really want. The actual behaviour seems to vary greatly depending on the type of element. I have half a mind to write all this up for the benefit of future Se-ExtJs testers, as it all seems very trial-and-error and tedious. But ultimately it seems like it can be made to work nicely. And, of course, this is in no way a reflection on Se. Whether it reflects poorly on ExtJs, I'm not really sure, but it is amazing how many DIV tags even fairly simple projects create.
This is probably a 'well OBVIOUSLY' but to anyone else doing this, I'd recommend getting comfy with XPath. It seems a bit obtuse at first but after a few hours, as noted above, you can find almost anything with it, and almost always in ways that are not overly brittle.
Happy Holidays!
Selenium is one of the backends to the TestPlan testing framework and it can address a few of these issues for you.
We don't seem to have any problems here. Our front-end uses many different locator syntaxes to locate any elements on the screen. Though if your page is complicated and Selenium truly can't do it then ours won't help you either.
We base everything on XPath, so after a while you just get used to it. There are all sorts of shortcut syntax that you can use in XPath that may help. In TestPlan scripts however you can also use variable expansion in XPaths which makes them much easier to maintain.
TestPlan caches browser sessions when possible and not otherwise requested. This helps the speed a little bit, but only so much since normally you want a fresh session for each test anyway.
TestPlan