My team has an automation solution that uses watir. In fact, we have 2 versions of it, one for one release of our software and another for another release. I find that changing versions of watir used it not easy, so I want to select the right version for my new project (building an exploratory framework like Jim Knowlton talks about on Watir Podcast #30).
Our product supports IE and Firefox. It could support other browsers in the future such as Chrome or Safari. Most of the interface technologies are supported by watir, though we created a webdriver framework to have better access to attributes.
So I am thinking that the Watir Webdriver may be the best choice for me today. Not having used it or even reviewed other people's happiness with it, I am just not sure if it is ready. What do you think?
I consider watir-webdriver with the Firefox driver ready for production use at this point, with some notable exceptions:
Frame support still needs more work
Alerts/prompts not supported
Table API is incomplete/unfinished
Having a stable and usable Firefox driver is my #1 priority, so I haven't yet spent much time testing IE, Chrome or HtmlUnit (remote).
The results from our spec suite (the watir2 branch of watirspec) should give a nice indication of how well the browsers are supported:
Firefox: passing: 94%, total time: 201 seconds.
Chrome: passing: 89%, total time: 1207 seconds.
IE: passing: 83%, total time: 2238 seconds.
Please check out the watir-webdriver extension alerts.rb
just do
require "watir-webdriver/extensions/alerts"
alert do
#...code that launches an alert box...
end
confirm true do
#...code that launches confirm box...
end
The blocks even return the value of the confirm/alert box if you want to test for that.
Thanks, Jari
I have used it, and it is pretty good. I have used only Firefox driver, just to make that explicit. I have tried IE and Chrome drivers and those and not as good as FF one.
Related
I am new to TOSCA, kindly guide me How to Launching multiple browsers in TOSCA?
Thanks in advance.
Sreeni
Additionally to what Kapil said above (which was about using browsers), here is how you can actually "launch" (=start) browsers.
Tosca treats browsers like any other application - you can start a browser using the TBox Start Program module (that you can get access to by importing the standard subset).
Tosca's manual actually provides an example of how to start Internet Explorer using that module, it works in a similar fashion with the other browsers. Here is a screenshot:
For the sake of completeness, here's the link to the manual for more details: https://support.tricentis.com/community/manuals_detail.do?lang=en&version=10.0.0&url=ep_tbox/process_operations/process_operations.htm
We cannot trigger multiple browsers in TOSCA, but it supports cross browser execution. For cross browser execution:
1. Create a Test Configuration Parameter "Browser" either at TestCase or at its parent levels.
2. We can choose value InternetExplorer, Firefox, or Chrome.
3. The execution will be triggered on respective browser.
In order to achieve parallel execution we have to go with Distributed Execution (DEX).
I have a Website which has a disclaimer which says that this web site is best viewed on IE7, 8 & 9, Firefox 12,13 and 14, Chrome 18, 19 & 20.
This disclaimer was put many months back.
But, new versions of Chrome and Firefox gets updated on User's system if auto-update is enabled.
Till now, whatever latest version of Chrome (CH 23) and Firefox (FF 17) that User's are using, my web site is supporting in terms of CSS and alignments. A day might come when a particular browser version will be released in which they internally update something and that might affect my CSS, Ajax calls etc. Am particularly bothered about look and feel.
How to find out beforehand if the Browser version which is getting released will start showing up my site properly. And that I dont have to start making any code changes.
For eg., IE10 is released and I had not targeted this during development. What parameters I need to check to make sure that I dont have to do any code changes.
First, the whole "best viewed in" thing is a throwback to the past when different browsers had substantial differences in how they rendered HTML, it's essentially pointless if you're developing properly these days.
Second, it's rare where a newer version of a browser will break display functionality of a normal website, I've seen it happen with some games and the newer versions of Chrome, but never a normal site. Browsers generally move forward in their display abilities but never at the expense of previous versions. You can still build a website with frames, tables and HTML font tags and it will still display properly so honestly I think you're worrying unnecessarily about something that isn't likely to happen.
That being said, Chrome has their Canary browser, which is their development version of Chrome with the latest toys and tweaks, IE will usually release preview versions of their browsers before going public as they did with IE10, not positive about Firefox or Safari but a quick Google should help you there.
Do keep in mind that developing for unreleased versions of browsers is a horrendously bad idea. They can change before release breaking what you've done. Make sure your code is clean and error free and works on current browsers and the chances a new browser release will break that code ranges between slim and none and is a lot closer to the none end of the spectrum.
I am studying CSS3 and HTML5 and trying to develop a simple homepage. Since I have only Mac interface in my house so I couldn't check any differences on windows.
But one day, one of my acquaintances told me that there is a pixel difference between browsers which I didn't know at all. Then I checked my page and it appeared to be wrong.
Even though it was same resolution as I set, Chrome on Mac showed me an appropriate position of several buttons but Chrome on Windows didn't.
Their position was quite different and ruined the design. How can I fix this problem? or is it normal?
Thanks.
Developing a site that is the same on every combination of operating system and browser is no easy task. It has personally added many hours to my development time trying to fix the issues.
There are several tools out there that try to help you with this task, such as Cross Browser Testing. Or you can manually test it by installing the browsers on your machine. It is also common to use virtual machines to test your website on other platforms. VMware is popular.
Using cross browser libraries can also aid in this. Such as jQuery, which is very popular. This page lists more information on the subject, in general.
Difference is not in Chrome, but difference is in Mac and Windows.
Here, you can detect the userAgent and add the appropriate class to the body tag (with jQuery):
jQuery(document).ready(function(){
if(navigator.userAgent.indexOf('Mac') > 0){
jQuery('body').addClass('mac-os');
} else {
jQuery("body").addClass("pc");
}
});
After detecting userAgent, you can write css specially for Mac and Window and their browsers too.
In 2018 chrome and firefox behave differently depending on the operating system. I built a site recently, and on latest chrome and firefox versions one page was rendering OK in windows, while on macOS and ubuntu, it had a small glitch. The elements that are supposed to be inline were displaying horizontally in certain states.
I am working on 4 internal websites, everyone should be using IE but not everyone is.
Is there an easy way to force the user to use IE, ideally without installing anything new like JQuery?
Cheers,
Kohan
Addendum
I really shouldn't have to justify why i'm wanting to do this, but here goes.
This site is totally internal and 98% of the users do not have the rights to install a new browser... however there are a select few that do. This is fine for most of our sites, but since these sites are very old, they do not work in anything but IE. I could fix it for all browsers... but it is a better use of my time to just put a "hot-fix" in for now as it will likely all get rewritten next year. The site itself is also only used once a year. It's simply not worth the time investment in this case.
Thanks
Kohan.
If you really wanted to do this you could check the user agent of each request and if it's not IE redirect to a holding page explaining that they need to change browsers.
var userAgent = HttpContext.Current.Request.UserAgent;
Alternatively use the Request.Browser property.
if(HttpContext.Current.Request.Browser.Browser != "IE")
{
// do stuff...
}
You could find the browser type, and if its not IE, then do a Response.Redirect() to a generic "Use IE" page.
if (!(Request.Browser=="IE")){
Response.Redirect("UseIE.aspx");
}
You'll have to check the return values of Request.Browser though as I'm not certain without testing
I'll suggest something eretical: instead of fighting against Internet Explorer, force the users to use the Google Chrome Frame It's a "plugin" for Internet Explorer that make the page work as if they were in Chrome.
I'll quote from that page:
Google Chrome Frame is an open source plug-in that seamlessly brings
Google Chrome's open web technologies and speedy JavaScript engine to
Internet Explorer. With Google Chrome Frame, you can:
Start using open
web technologies - like the HTML5 canvas tag - right away, even
technologies that aren't yet supported in Internet Explorer 6, 7, 8,
or 9.
Take advantage of JavaScript performance improvements to make
your apps faster and more responsive.
Now your users can have IE 6.0 to work with their obsolete internal web applications AND you can work against a "unified" (you are programming only against Chrome) "modern" web browser.
I am trying to debug a large and complex webapp that makes heavy use of DIVs, AJAX, dynamic HTML and server-side code to do its job.
Under normal operation we do not have problems. However, when we put the webapp into an IFRAME, certain functions trigger a crash in IE7 that renders the browser inoperable (all CPU used).
What tools exist to help track down what could be happening? Loading the IE process into the debugger gives me all sorts of fascinating info about the registers, but I think the issue is in javascript.
We have tracked down one problem with the app already that involved incorrect reparenting of an element (something attached itself to window. instead of document.)
I wrote a test IFRAME page that dumps the innerHTML of the iframe into a textarea, so it can be compared during various states, but that only shows me static attributes, I can't tell what sort of javascript events are associated with elements or determine if a handler is firing out of turn.
IE8, Firefox, Chrome etc do not have the same behaviour.
Ideally I'd like something that would let me snapshot the DOM (or the javascript VM?) during a known good state, then "just before it happens" so we can figure out what's added / removed / missing / different. What is out there?
Update: I'm now trying to use the IE Developer Toolbar to track it down.
Update 2: The IE7 crash occurs following this AJAX code:
function Sys$UI$Control$get_element() {
/// <value domElement="true" locid="P:J#Sys.UI.Control.element"></value>
if (arguments.length !== 0) throw Error.parameterCount();
return this._element;
}
The return this._element; line is the last thing that happens before I lose IE.
IE Developer's Toolbar. Download it here (IEDevToolBarSetup.msi).
For JavaScript debugging refer this blog.
Some guy made a bundle that's called Internet Explorer Collection. It includes some 6 different IE browsers ranging from IE6 to IE8 in different builds. All those include Firebug (really, it sort of works) and Internet Explorer Developer Toolbar.
It was really helpful for me to debug IE7 issues.
see this link.
By placing 'debugger' in the javascript files in places where you'd like to start debugging you can debug the javascript in visual studio as well complete with trace, call stacks, etcetera.
The IE developer toolbar definitely helps alot. Visual Studios's debugger is also very good if you can get a machine with VS and IE7 on it.
DynaTrace is a profiling tool for IE7. However, it provides a great deal of information (including JS stacks), so it can also be very helpful for debugging.
IE 7 and IE 8 has built in debugging tools. Press F12 and you are ready to debug. Also firebug-firefox and chrome's inspect element options are useful/