I was just wondering if this was the default behaviour when starting up Intern with a Selenium Tunnel. At the moment, before running any tests, random pages that appear to look like the Intern-tutorial, which I used to learn how to run tests with Intern, seem to come up before attempting to run any of my own tests.
I have set up a vanilla install with no tests set up to demonstrate this behaviour. Please see the video link given below as reference if I have been unclear.
https://www.youtube.com/watch?v=vC15PbjSxVw
Leadfoot, which is the WebDriver implementation used by Intern, performs feature and defect tests on the browser before testing starts. These tests tell intern about features that a particular browser might not support, or might implement incorrectly, giving Intern (well, Leadfoot) a chance to work around them.
Can anyone explain what is running selenium tests in headless mode in jenkins?
As per comment it's a way of running tests in a browser that doesn't have a GUI attached to it
What is a headless browser? (Quoted from ToolsQA)
Headless browser is a term used to define browser simulation programs
which do not have a GUI. These programs behave just like a browser but
don’t show any GUI. Famous ones are HtmlUnit and the NodeJs headless
browsers. There are a good number of more browsers too.
What is the use of Headless browsers?
Headless browsers are typically used in following situations
You have a central build tool which does not have any browser installed on it. So to do the basic level of sanity tests after every
build you may use the headless browser to run your tests.
You want to write a crawler program that goes through different pages and collects data, headless browser will be your choice. Because
you really don’t care about opening a browser. All you need is to
access the webpages.
You would like to simulate multiple browser versions on the same machine. In that case you would want to use a headless browser,
because most of them support simulation of different versions of
browsers. We will come to this point soon.
Things to pay attention to before using headless browser
Headless browsers are simulation programs, they are not your real
browsers. Most of these headless browsers have evolved enough to
simulate, to a pretty close approximation, like a real browser. Still
you would not want to run all your tests in a headless browser.
JavaScript is one area where you would want to be really careful
before using a Headless browser. JavaScript are implemented
differently by different browsers. Although JavaScript is a standard
but each browser has its own little differences in the way that they
have implemented JavaScript. This is also true in case of headless
browsers also. For example HtmlUnit headless browser uses the Rihno
JavaScript engine which not being used by any other browser.
I am looking for a tool to functionally test my Yii/ Node.js web application. The first thing I looked into was Selenium. The app runs on a headless Ubuntu server so successfully setting up xvfb and run a test was really painfull and drove me to another tool.
The error I kept getting is:
Xlib: extension "RANDR" missing on display :0
The other tool was Casperjs along with Phantomjs . Aside from the 5 minute setting up, I wrote few tests and integrated all with Jenkins CI. I really believe there should be more tools like this one. So I feel I've earned something on the short term, but I'm afraid that on the long term I'll hit a dead end. Could you give me some feedback? Am I going the wrong road?
Another thing that's crossing my mind is to setup the Selenium RC and Jenkins on a Windows machine with all browsers set up. I think this will give my tests a better and more accurate perspective.
* I would also like to be able to do some parallel functional tests (interactions) since the website is socket-driven. Does Selenium handle that?
First off, don't use Selenium RC if you can avoid it, it's officially deprecated in favor of Selenium Webdriver (also known as Selenium 2).
About headlessness - Webdriver can be easily run on top of HtmlUnit and also PhantomJS - both should work right away.
If you want to run the tests on actual browsers, people have been successful in running that on headless systems, too, but as you said, it's a pain. Instead, you can run the tests remotely on a different machines with your headless server commanding them all.
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?
So I came across zombie.js, is this a headless browser?
If so, what browser engine does it use?
Could I rely on it for doing lot of automated tests? Basically, I am restricted to a single server, so I would like to squeeze as many browser tests as possible.
Currently, I am relying on Selenium FirefoxDriver to run my tests. How would zombie.js compare in performance and efficiency to Selenium Webdriver browser instances running? However, there's limitation to how many browser instances I can run in parallel.
Yes, Zombie is headless.
"Whick browser engine?" - > well, it uses a mixture of technologies:
for Javascript: V8 from Chrome (run by node.js)
for DOM: JSDOM
for HTML5 parsing: https://github.com/aredridel/html5
Performance: should be much faster, according to author's statement: http://labnotes.org/2010/12/30/zombie-js-insanely-fast-full-stack-headless-testing/
is this a headless browser?
I haven't used it, but it certainly looks like a headless browser:
If you're going to write an insanely fast, headless browser, how can you not call it Zombie? Zombie it is.
Zombie.js is a lightweight framework for testing client-side JavaScript code in a simulated environment. No browser required.
what browser engine does it use?
From http://zombie.labnotes.org/guts.html#Grocking:
The DOM implementation is JSDOM, which provides an emulation of DOM Level 3.