I am using PhantomJS (headless end to end testing),selenium webdriver,grunt(task runner) for my application testing. My requirement is that the application should be compatible with IE-9. I have to do headless testing because I'm using jenkins for continuous integration.
How do i make sure that my application will run perfectly on IE-9
while testing on phantomJS ?
You can't use PhantomJS for testing compatibility with Internet Explorer, because it is a Webkit browser.
Since you're using Selenium, you should be able to use the IE WebDriver.
Some thoughts on why you can't even simulate IE in PhantomJS:
They are built on different base technologies. They use different rendering engines and both have different bugs when it comes to adhering to W3C specifications.
JavaScript bugs may be simulatable, but this requires you to go ahead and fix all bugs that PhantomJS has in comparison to your specific IE version by exchanging the implementation of some browser APIs. You would also need to introduce some bugs that are present in your IE version, but not in PhantomJS again by exchanging implementation.
CSS bugs can only be introduced if you change the WebKit implementation and compile it again. You would have to find them first.
Great, you have effectively reverse engineered IE.
Related
I need to test javascript on IE8 but since I updated I cannot install IE8. What do developers do in this situation?
The most reliable way is having multiple virtual machines installed on your computer (or on a testingstation) that run different windows versions and IE versions.
There is no way to install IE8 or multiple IE versions at the same time on one windows installation.
You find all windows versions and IE versions here and also some instructions how to set up the virtual machines.
Another way is to use the tool IETester, which only runs on windows and kind of simulates different IE's. It never really felt reliable to me.
There are also different companies, which provide multi-browser testing suites. They allow you to remotely test browsers (including IE8) remotely on their servers. For example Browserling or Browserstack.
Use a VM! Get something like virtualbox and you can get the box from Microsoft https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/
You can use the emulator built into 11 but know that it's not a direct emulation and isn't the real thing. A VM will create a new machine that is running a paired down version of windows and the browser.
If you open the developer tools there is a button on the top right corner which allows you to run the browser as an older version of IE:
I am new the Cross Browser Testing and just starting to look at Selenium however I can't seem to find the answer to the followings on the official site. It would be much appreciated if someone can help clarify for me.
Does Selenium integrate "independent browsers" (via webdrivers) or uses/links existing browsers installed in the OS?
If Selenium uses "independent browsers", can it actually "open" for instance say IE7, IE8, IE9, IE10, Safari in OS (say windows) separately after which you can test the UI?
1) The browsers that you want to be tested should be installed in your machine. so the answer is it uses existing browsers.
2) No. You have misunderstood.It can automate only the browsers available in the OS. BTW, you can not have multiple version of same browsers in same machine... unless you run from a pen drive.
Using RemoteWebDriver and Selenium Grid, you can have different machines hosting different versions of browsers.
The tests will still execute on your machine but the browser will open on a machine which has the version you define in the test.
This is especially useful when running tests as part of a CI build when the CI server will often not have browsers installed.
Building and maintaining your own grid can be time consuming so companies such as Saucelabs provide a cloud solution in which you point your tests to open browsers on their grid. They have most combination of browsers, versions and os.
I am investigating frameworks to automate testing of javascript application different browsers: IE, Chrome, Firefox etc. I would like to include it as part of my Jenkins CI pipeline.
I have looked at:
How to use remote browsers for js-test-driver task on Jenkins?
https://code.google.com/p/js-test-driver/wiki/GettingStarted
http://www.browserstack.com/automated-browser-testing-api
(fair pricing)
http://docs.seleniumhq.org/
(seems a bit dated)
Am I missing some currently recommended tools to use for CI and automation of browser compatibility testing?
Here's a list that you can expand your search farther.
http://en.wikipedia.org/wiki/List_of_GUI_testing_tools
I've used Selenium, integrating it with Jenkins and it's worked well.
Are there any headless browsers for node.js that support dumping a rendered page out to a file? I know phantomjs supports rendering to a file, but it doesn't run on node.js. I know zombie.js is a node.js headless browser, but it doesn't support rendering to a file.
I doubt you will find anything that is going to work as well as phantomjs. I would just treat the rendering as an async backend process and execute phantom in a subprocess from your main node.js process and call it a day. Rendering a web page is HARD, and since phantom is based on WebKit, it can actually do it. I don't think there will ever be a node library that can render a web page to a graphic file that isn't built upon an existing browser rendering engine. But maybe one day phantomjs will integrate more seamlessly with node.
Try nightmare, it uses the electron, it is way faster than phantomjs, and it's API easy and uses modern ES6 javascript.
This might look like a solution with a little bit overhead...
You can use the Mozilla Firefox with the MozRepl plugin. Basically this plugin gives you a telnet port to your Firefox which allows you to control the browser from the outside. You can open URLs, take screenshots, etc.
Running the Firefox with the Xvfb server will run it in headless mode.
Now you just have to control the browser from the outside with node.js. I've seen a few examples where someone has implemented a http alike interface inside the chrome.js of Firefox. So you can run a http command to get a screenshot. You can then use http calls from node.js. This might look strange, it actually is but might work well for you.
http://hyperstruct.net/2009/02/05/turning-firefox-into-a-screenshot-server-with-mozrepl/
I'm running a slightly modified version in production with Perl Mojolicious in async mode to trigger the screenshots. However, there is a small problem. When plugins are required they do work, however Flash usually gets activated when it's in the visible area, this won't happen so movies/flash things might not get initialized.
You might find this helpful, though it's not javascript specific.
There is a webkit-based tool called "wkhtmltopdf" that I understand includes javascript support using the QT web-kit widget. It outputs a visual representation ("screenshot" if you will) of the page in PDF format.
FWIW, there are also PHP bindings for it here: php-wkthmltox
The Chrome dev team has released Puppeteer which can be used in node. It uses Chrome with the headless option.
There's a project called Node-Chimera. Although it's not as mature as Phantomjs, it has all the features you have mentioned: it runs on native Nodejs, and allows you to render pages to a file. Repository is here: https://github.com/deanmao/node-chimera. It has examples to do exactly what you need.
What are cons of force a web site viewed in IE to compatible mode? Say we force IE9 to IE8 compatiblity mode?
Performance drawbacks
Can't use any new IE9 specific features like HTML5/CSS3/SVG
Why?
We run legacy web app which is developed since 2000 so it's a mess ball fighting to be compatible with Chrome, Opera, Firefox, IE6/7/8 and now we decide to add IE9 to the list. But with IE9 we run in issues with printing, "Permission deniend" JavaScript errors (probably something about cross-frame JavaScript calls) and next issues - the easy workaround is to force IE9 to behave as a IE8 and then everything works fine. But I am still not sure if it's way to go...
first our app is public site (for our clients)
You have a public website developed in 2000 and it doesn't work on modern browsers? Deprecate it or re-write it.
Don't hack your code to support modern browsers, the website is clearly poorly written and doesn't apply to standards. You can't get away with this.
The only place where you can get away with this level of incompatibility is intranet applications and even then you should simply state "it works on browser X, live with it"
You can't say that to public facing clients. I mean you can try, but have fun losing business to your competitors.
Re-develop your website to match the W3C HTML/CSS standards and the ES5 standards and it will be completely future facing (for some years).
Alas, the way the web works is that anything more then 5 years old is deprecated. So either re-write it every 5 years or get out of the web business.
In terms of actually using compatibility mode, don't. IE6-8 are horrible engines and should be avoided like the plague. If you use them then you can't write future facing standards compliant code.
Your code needs to match the standards and you should fix / shim / patch any browser specific bugs where those browsers don't implement the standards.
You cannot say you have tested in IE6/7/8/9 until you have tested in those different versions. Emulating the test environment is not the same as using the test environment. To my knowledge IE7/8 compatibility modes are the older render engines, not the underlying browser as a whole, bugs and all. It is closed source so you will never know.
Convert Microsoft's free to download virtual disk images for cross-browser testing to Virtualbox images and put them on a machine that just runs Virtualbox. An old machine will do, run the VMs headless and access them with remote desktop. In that way you will be able to test in all browsers without burdening your machine with MS/Spyware.
I believe your system admins can set IE to compatibility mode for all intranet traffic using the Group Policy Editor. Any site you create will from this point forward, you can add a meta tag to force IE9 to render natively and use all the newer features...
I'm having to do that on my current project using the following doctype and meta tag in my header:
<!DOCTYPE HTML >
<meta http-equiv="X-UA-Compatible" content="IE=100" />
Compatability mode is something that MS introduced to give people some chance to upgrade their applications, not for long term use. AFAIU.
If you want your application to be compatible with IE9, then you will have to change it. If you are trying to maintain IE6-9 compatibility then you have a real challenge, and you should consider whether this is really practical - in essence, you need at least 2 distinct sets of html. Is this practical for you?
IE9 compatibility mode is different form IE9 and IE8 - it draws bits from both. So you need to do a full test agaisnt the compatibility mode version, and ensure that it remains working against this.
So in answer to the question, the cons are that you are not being IE9 compatible, and there is a danger that when IE10 comes out, your code will not run against that in any mode. You are putting the effort into compatibilty testing without providing for future changes. You would do better, in the longer term, to make your code IE9 compatible. Also, the message you are giving your clients is that your code base is not going to be compatible for much longer. Unless you are talking to them about a re-work, this is a real negative.
However, it sounds like your entire code needs a re-work, to forget about IE6 and be written for modern working browsers. Using compatibility mode until that happens is probably OK. If you do this - and tell your clients - then staying in compatibility mode is viable.
Using compatibility mode will NOT cause the browser to use the JavaScript engine that was present in the old version of IE.
By that I mean it will run any JavaScript code using the IE9 engine. Which was a problem for us when debugging an old product that had a problem with IE7/8.