A headless WebKit that offers native and quick support for a number of web standards. PhantomJS is scriptable with a JavaScript API and permits webpage capturing, pages manipulation, access to the file system and page settings. Also, it contends with mobile Webkit, which supports touch events.
Headless web testing with JavaScript
PhantomJS has a whole set of features that testers love and use for many purposes. It is primarily used for headless testing of web applications. PhantomJS fits for both as a part of a constant integration system and universal command-line based testing. It is important to recall that PhantomJS itself is not a testing framework, it is only engaged to launch the tests through a suitable test runner.
It is a headless WebKit which means that it delivers the layout engine related to those that are used by Firefox, Safari, Chrome or other niche browsers. Basically, PhantomJS is a browser itself where pages are never actually displayed even though it is a headless one. PhantomJS code targets at directing browser automation at a high level. Many other widely used testing libraries can run on top of PhantomJS, even though it is not a testing library including Jasmine, Mocha, Capybara, WebDriver, QUnit, FuncUnit, YUI Test, BusterJS, Robot Framework etc. In-state when the framework does not need an external runner, it is marked as "built-in".
PhantomJS advantages are:
1. Screen capture: Since PhantomJS uses a realistic rendering and layout engine, it can be used to seizure web contents, convert it not only in CSS and HTML but also into Canvas and SVG and build server-side web graphics apps from a screenshot service to a vector chart rasterizer.
2. Network monitoring: PhantomJS licenses the examination of network traffic and it is possible to automate track page loading, performance analysis and export as standard HAR format.
3. Page automation: It is quite easy to manipulate web pages and load with the usual libraries like jQuery or with the standard DOM API.
4. Continuous Integration: Integration and Support with the CI systems (e.g. Jenkins testing tool and TeamCity) do not request for special setup since it is virtuously headless on Linux and the agent can run on an installation with any GUI which means that a barebone Linux system without X11 is not a problem for PhantomJS. It makes it likely to spawn light build agents on Heroku instances or Amazon EC2.
5. PhantomJS testing: Since it is possible to manipulate and access web pages with PhantomJS, it is appropriate to carry out various page automation. Furthermore, some projects are built on top of this WebKit so as to provide high-level functionality for testing purposes. For Example:- js(suitable to testing and build scripted navigation), WebSpecter (BDD-style acceptance test framework for web applications), Lotte (contains jQuery-like chaining, more assertion logic and methods).
PhantomJS also comprises run-jasmine and run-qunit in its example subdirectory. These lack important reporting features which are necessary for real-world uses and are for design purposes.
Pros and cons of using PhantomJS instead of real browsers.
Pros:
1. Most people use PhantomJS to avoid additional overhauls with real browsers and it's headless.
2. You can avoid the Grid Hub relationship(or another similar mechanism) by running the tests on CI directly using this which is sometimes a little messy to handle.
3. Runs multiple test cases faster in automation testing so run-time can be reduced by up to 50% for most tasks.
4. Best suited for smoke testing of applications.
5. It requires a lesser number of resources.
6. Able to run far more instances simultaneously than non-headless drivers.
Cons:
1. There is a large number of pending issues in PhantomJS.
2. While UI and e2e testing are frequently used to imitate the user behaviour PhantomJs does not exactly do that.
3. There are some cases where PhantomJS fails but other drivers work perfectly.
4. Hard to debug inconsistent failures on locating elements due to too fast page loading.
5. For non-headless drivers the code will not always work when the driver switches to HtmlUnit i.e. the switching between ChromeDriver and FirefoxDriver is usually consistent in success rate with the same code, but the same is not the case with HtmlUnit.
