When comparing PhantomJS vs xvfb, the Slant community recommends PhantomJS for most people. In the question“What are the best headless browsers for testing?” PhantomJS is ranked 1st while xvfb is ranked 8th.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Supports screen capture
Pro Used in many open source projects
Pro Supports many browser standards
PhantomJS has full DOM and CSS parsing, JSON, canvas, and SVG support.
Pro Built on WebKit
WebKit is becoming the gold standard for browser compatibility, making it a good starting point for native headless browser testing.
Pro You can launch REAL browser using xvfb
Just test in real-world browser - xvfb makes it possible to launch them without the real screen.
Cons
Con Deprecated by Puppeteer
PhantomJS is no longer actively maintained by the original authors. Puppeteer is said to be a replacement supported and backed by the Google Chrome team, now.
Con Heavy setup
You'll often end up having PhantomJS binaries connected via WebDriver to your testing framework, possibly using client/server especially if you want your test running with something else than Java. This means an overhead in terms of maintenance and performance, but still usually lighter than running a full browser (like Chrome, Firefox, IE).
Con Browser closes unexpectedly
It often happens when running on more then 5 (my measurement) JVM instances that the browser gets stuck and quits unexpectedly. This can be partially solved by running the instances one by one instead of parallel (this is a problem when testing Jenkins and Bamboo agents) but I don't believe this qualifies as a solution. The error is called UnreachableBrowserException
.
Con Elements are sometimes not visible
This is an error which occurs with almost no reason, PhantomJS sometimes decides that it cannot click the element even though the element is intractable or enabled.
This happens if you have to scroll to see the element (and these are not pages that load elements with JavaScript) which is strange because PhantomJS should catch the whole page if it is not loaded explicitly with JavaScript. This problem partially goes away with re-sizing the browser, but that does not really qualify as a solution.
The error it raises is: ElementNotVisibleException
.
Con xvfb is no browser
Con Problem with ports
If you are running multiple instances on some browser and you use xvfb to run instances on agents on Bamboo or Jenkins you will potentially have a problem with using ports.
The first instance you are starting takes on a port on the agent and then the second instance that would be run doesn't have a port to go to.
You can partially solve the problem by dynamically assigning the next available port to the new instance that comes to be executed.
This only works if we assume that all the instances start in different time intervals, but what you cannot know is which instance is going to get a port first if they start at the same time, then the instances will crash, those that started at the same time.