Over 2 years I tested web application with help Selenium framework. I know the best design is testing on VM.
The only one downside of this - it's very slow testing. Why?
browser only gets so much memory, if you will run several instances.
site coud be very slow.
connections can be very slow.
Would be great if there was a framework that emulated the browser (engine/core) correctly and can provide some results (api) for surf on the page.
I don't mean to simulate just on the one browser with different version (like IE). I mean to simulate for all browsers with very popular and newest version.
Does anyone know a framework/tool that can do it?
Thank you.
You can try PhantomJS for example.
From their page:
PhantomJS is a headless WebKit with JavaScript API. It has fast and
native support for various web standards: DOM handling, CSS selector,
JSON, Canvas, and SVG.
You can use it in combination with Jasmine (as well as several other frameworks) for testing.
However the selection of available engines is limited to WebKit. I doubt that Selenium will be easy to replace. By the way it looks like Selenium will probably become a W3C standard over the next years.
You can also run Selenium with Xvfb - I use it to execute test on remote server and it is going very well.
Related
I'm looking for a reliable application/tool for automation using headless browser.
Looked into htmlunit and httpunit and as far as I understand, they were built in and 'era'
way before modern Javascrips became available therefore using them may result some issues.
Then I looked further and apparently it is possible to use Selenium (Which I have used before)
in conjunction with the htmlunit driver.
I'm confused. Firstly, why would you use Selenium with htmlunit? Which API's are called during the test, Selenium's of htmunit's? The other thing is why would anybody chose to use htmlunit knowing it does not support modern web sites ?
Thanks in advance.
Firstly Selenium with HtmlUnit supports JS at present time, but with some limitations:
When we say "javascript" we actually mean "javascript and the DOM".
Although the DOM is defined by the W3C each browser out there has its
own quirks and differences in their implementation of the DOM and in
how javascript interacts with it. HtmlUnit has an impressively
complete implementation of the DOM and has good support for using
javascript, but it is no different from any other browser: it has its
own quirks and differences from both the W3C standard and the DOM
implementations of the major browsers, despite its ability to mimic
other browsers.
Reference
Firstly, why would you use Selenium with htmlunit?
HtmlUnitDriver is by far the fastest implementation of WebDriver. Some times you just don't care about JS execution - there really are still sites like this. There are definitely tons of reasons. For example I have used it to do simple administration tasks.
Which API's are called during the test, Selenium's of htmunit's?
You would be using WebDriver's API that would make calls to the browser.
There is something similar here.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am trying to understand testing framework better and been looking into Selenium. I've used HTMLUnit before, mainly when I needed to scrape some information off website or the likes.
In the context of writing test automation, what's the advantage / disadvantages of Selenium vs HTMLUnit? Looks to me Selenium is more complicated to set up than HTMLUnit, although at the same time there's a HTMLUnitDriver for Selenium which I think behave the exact same way as in HTMLUnit itself?
Selenium obviously provides more robust framework, it has the Selenium RC for pararel testing, it also has different browser drivers that can be used - although when you used the browser drivers, the test will actually open/close a browser application rather than headless.
May be I am not understanding Selenium correctly. Some directions and pointers would be great!
On another note - a separate question - I am also looking at doing automated testing on mobile browser, I see that Selenium has an IPhoneDriver for it, but then this is not a headless testing either as it requires actual iOS simulator.
Is there anyway to do headless testing on mobile sites? Would changing user-agent be sufficient? I've seen a couple posts around changing user-agent that seem to have their own challenges, eg. Set user-agent in Selenium RC
Thanks a lot!
well, would try to explain differences in detail.
Speaking about parallel testing, it better to use selenium grid.
Basic concept of selenium RC and selenium grid.
You can get into more details here
Some words about selenium webDriver:
The primary new feature in Selenium 2.0 is the integration of the WebDriver API. WebDriver is designed to providing an simpler, more concise programming interface along with addressing some limitations in the Selenium-RC API. Selenium-WebDriver was developed to better support dynamic web pages where elements of a page may change without the page itself being reloaded. WebDriver’s goal is to supply a well-designed object-oriented API that provides improved support for modern advanced web-app testing problems.
How Does WebDriver ‘Drive’ the Browser Compared to Selenium-RC?
Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and the features they support depends on the browser you are using. Information on each ‘browser driver’ is provided later in this chapter.
For those familiar with Selenium-RC, this is quite different from what you are used to. Selenium-RC worked the same way for each supported browser. It ‘injected’ javascript functions into the browser when the browser was loaded and then used its javascript to drive the AUT within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation.
WebDriver and the Selenium-Server
You may, or may not, need the Selenium Server, depending on how you intend to use Selenium-WebDriver. If you will be only using the WebDriver API you do not need the Selenium-Server. If your browser and tests will all run on the same machine, and your tests only use the WebDriver API, then you do not need to run the Selenium-Server; WebDriver will run the browser directly.
There are some reasons though to use the Selenium-Server with Selenium-WebDriver.
You are using Selenium-Grid to distribute your tests over multiple
machines or virtual machines (VMs).
You want to connect to a remote machine that has a particular browser
version that is not on your current machine.
You are not using the Java bindings (i.e. Python, C#, or Ruby) and
would like to use HtmlUnit Driver
Selenium-WebDriver’s Drivers
WebDriver is the name of the key interface against which tests should be written, but there are several implementations. These include:
HtmlUnit Driver
This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit. HtmlUnit is a java based implementation of a WebBrowser without a GUI. For any language binding (other than java) the Selenium Server is required to use this driver.
Pros
Fastest implementation of WebDriver
A pure Java solution and so it is platform independent.
Supports JavaScript
Cons
Emulates other browsers’ JavaScript behaviour (see below)
JavaScript in the HtmlUnit Driver
None of the popular browsers uses the JavaScript engine used by HtmlUnit (Rhino). If you test JavaScript using HtmlUnit the results may differ significantly from those browsers.
When we say “JavaScript” we actually mean “JavaScript and the DOM”. Although the DOM is defined by the W3C each browser has its own quirks and differences in their implementation of the DOM and in how JavaScript interacts with it. HtmlUnit has an impressively complete implementation of the DOM and has good support for using JavaScript, but it is no different from any other browser: it has its own quirks and differences from both the W3C standard and the DOM implementations of the major browsers, despite its ability to mimic other browsers.
With WebDriver, we had to make a choice; do we enable HtmlUnit’s JavaScript capabilities and run the risk of teams running into problems that only manifest themselves there, or do we leave JavaScript disabled, knowing that there are more and more sites that rely on JavaScript? We took the conservative approach, and by default have disabled support when we use HtmlUnit. With each release of both WebDriver and HtmlUnit, we reassess this decision: we hope to enable JavaScript by default on the HtmlUnit at some point.
To investigate deeper into webDriver's setUp see this
From HtmlUnit documentation:
HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit or TestNG.
So to conclude Selenium and HtmlUnit difference:
HtmlUnit is a java based implementation of a WebBrowser without a GUI and a way to simulate a browser for testing purposes and Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. we can see that HtmlUnit provides API without GUI possibility for automation whereas WebDriver provides internal browsers' possibilities for automation.
Speaking about mobile automation,
Selenium also has an iPhone Driver
iPhone Driver wiki article
and Android Driver
Android Driver wiki article
See also this presentation
Unfortunately I can not give you my working experience evaluation of mobile drivers as I deal with web automation (no mobile). Also know that Cucumber (automation tool) is popular among mobile automators.
see this and this.
Hope it come a lil bit more clear for you now =)
Selenium and HTMLUnit are somewhat similar in concept, but Selenium is more mature/robust and has a lot more features.
Note that Selenium encompasses the recording (IDE) plugin for Firefox, which allows you to record tests and the RC/WebDriver automation framework which essentially drives a browser. The two can be used together to make test creation very easy.
The only advantage I could see to using HTMLUnit is that it is less resource intensive, so you could potentially run tests on less hardware, but with Selenium's parallel support even that isn't really true anymore.
When running tests from Jenkins overnight, you typically have no access to a windowing system such as X11 or Windows in which to run the web browser. I therefore see a benefit of using the HTMLUnit web driver in that case since it doesn't require access to a windowing system.
In my experience, HtmlUnit does a fine job with browsing automation, but might get a bit buggy when dealing with Javascript. I actually came to a case in which I wasn't able to automate an image download with HtmlUnit, and had to turn to Selenium, which performed beyond my expectations. The case is actually registered in an SO thread.
I have used Selenium WebDriver for automation.
There is a very easy method to causing the browser to be headless.
Simply apply ChromeOptions (In my case, other DriverOptions are available)
ChromeOptions("Headless")
There are many proficient methods that can come from using Options or Services, as another example
This will stop the Driver/CommandPrompt window from 'appearing' so it will remain 'silent' and unexposed.
ChromeDriverServices ("Silent")
At least at UX systems you can use for example Xvfb and point the browsers to that display to make them "headless"
See also http://infiniteundo.com/post/54014422873/headless-selenium-testing-with-firefox-and-xvfb
or How do I run Selenium in Xvfb?
What's the pro's and cons for both and why should I use either of them for functional testing?
Regards,
Jonas
Selenium is for integration testing, It will test how your web application behaves in an actual browser. This can find things that HTTPUnit cannot, e.g. browser compatibility of css and JavaScript.
HTTPUnit tests web applications by directly calling the web service and manipulating the response. This is a functional test framework as it tests what your web app does, not how it behaves across different platforms.
One advantage of HTTPUnit is that it is much quicker than Selenium. Personally I would (and do) use both. HTTPUnit for complete functional testing and Selenium for selective (not complete) integration testing to check browser compatibility.
HttpUnit is very simple, extremely easy to use, and requires very little to get up and running. It's a good place to start for simple tests, however it will require more coding to create complex tests.
Selenium is more than just a library, like HttpUnit. It equips you better for more advanced, stateful tests.
Selenium will use your browser to automate tests
- Selenium http://seleniumhq.org/
httpunit goes from the html specification and simulates a standards conformant browser
- httpunit http://httpunit.sourceforge.net/
Selenium is more specific and will let you use browser specific behaviour and not limit the application under test.
With httpunit the limits are set by what httpunit supports which is far less than most browser do. E.g. the javascript capabilities are reduced to a very small set. On the other hand if your app passes httpunit tests it will probably run on quite a few browsers and environments.
So if you are interested in supporting a mininimal common set of features httpunit might be for you.
I have a project that will involve heavy automation of complicated web pages.
I realize there are Mechanize and Beautiful Soup, but don't these break when dealing with large amounts of DOM scripting and other weird stuff you find on complicated web pages?
I think I want essentially a barebones running instance of WebKit that allows me to either do "GUI scripting" or access the DOM. Ideas?
Try Sahi with PhantomJS. Sahi is a browser automation tool, and PhantomJS is a headless Webkit browser. You can find set-up instructions here: http://sahi.co.in/w/sahi-headless-execution-with-phantomjs
Disclaimer: We created the Sahi product.
What platform are you working on? And what language do you intend to use?
Adobe Air let's you embed a webkit inside an Air application and interact with the page JavaScript (there is two-way communication between the page JS and the AIR runtime).
Otherwise, if you are not bound to webkit you could take Mozilla Chromeless for a spin.
My apologies if none of this does what you need to do, I can't quite figure what exactly you are trying to do (page scraping? submitting forms?).
For testing/scraping i would try:
Selenium
EnvJS
Windmill
Watir
Sahi
WebTest
Tools like Selenium are good for testing user interactions on the web UI. However, I was curious what are people approaches for strictly testing and verifying that web pages are rendered correctly across a set of browsers?
Is this even possible?
May I recommend browsershots where you can submit pages and have them rendered out in a variety of browsers with various things set on or off such as Flash and JavaScript. At the end of the day you will still want to install FF, IE6-8, Opera and Safari/Chrome for testing manually. Also, if you've got a friend with a Mac (or a PC if you're using a Mac) get them to test in Safari too as I've personally found differences in the way both of them render the same page.
I'd also recommend that you develop mainly in Firefox and regularly check it in IE6 as you work. IE6 is the one that will mostly screw up so if it's working in both it's more likely to be working in all.
When you find rendering weirdness try and fix it in your markup and CSS first before resorting to CSS hacks as they can lead to 'interesting' problems later or in other browsers.
There is only a handful of browsers you need to test, as some share a common rendering engine (Gecko or Webkit). Without explaining which or why, here's the current wisdom (2009):
Build your site using Firefox or Opera (on any platform). BTW Opera uses its own Presto engine;
Test in whichever of the above you didn't use.
Validate the (X)HTML and CSS (important!).
Test it in >=IE7 and note the glitches, if any.
Use conditional comments in separate stylesheets for each version IE - never use CSS hacks as they'll go out of date.
Test in IE <7 if you like and do the same, or use conditional comments to ask users (politely) to upgrade their version of IE.
Test in Safari (Webkit).
Don't test in Chrome, you already have by proxy (Webkit)!
Don't test in IE for Mac - the share is too low and it's no longer updated.
Finally, try enlarging the text in Firefox, Opera, IE and Safari. Opera also has a hand-held emulation mode for mobiles.
You will have now covered (theatrical guess) 99.9% of browser setups. If you're on OS X or Linux, you can run Windows in a virtual environment like Parallels or Wine. Apparently Wine also has a Windows binary, but I couldn't find it. Caution: you'll need to be sure that your virtual environment allows IE to read conditonal comments.
In practice, I find that if a site has valid code and works in Firefox, Safari and Opera, it'll probably be okay in IE7 up. The only HTML/CSS gotcha is IE's 'haslayout' handling. If you don't have the browsers, BrowserStack is an excellent online testing service.
Finally, if you're using Javascript, you'll need to go through a similar process, problem being that as a rapidly developing area, newer versions of some browsers handle Javascript in increasingly effective ways, so functions in older versions might break or fail quietly.
If you just want to see if layout is correct, just submit your website to BrowserShots.org and visit later to see the screenshots.
If you want to test the functionality (JavaScript, etc.) then you'll need to test manually.
Manually?
I do not see an alternative if you want strict testing. Just install as many different browsers as possible and test in all of them. Of course this includes different versions of most popular browsers, and you need to check on Windows, Linux and Macintosh.
Previously I was use WM for different versions of IE, but I find out some new tool for testing layout, and UI as well with this tool, link for FF use fire bug extension, those tools are for manually testing.