I'm looking for a way to test an app or a website, which is not based on angularjs, on real browsers and real devices. I found CasperJS, but CasperJS only runs with headless browsers.
Are there test-runner/testing-framework combinations out there which support:
grunt
all major browser (Chrome, Firefox, Safari, IE)
headless browsers (PhantomJS)
(optional) simulate touch gestures
I would choose protractor. I know its main target is angular, but it works fine without angular as well. It has nice shortcut features. We use it to test non-angular sites and it looks stable enough. Otherwise it is based on webdriverjs, and it can work with phantomjs as well.
There is a good starter setup: https://github.com/angular/angular-seed
And this page can help to tune it for your requirements:
http://ng-learn.org/2014/02/Protractor_Testing_With_Angular_And_Non_Angular_Sites/
And the main urls:
https://github.com/angular/protractor
https://code.google.com/p/selenium/wiki/WebDriverJs
I didn't test the phantomjs part, but google says it should be fine.
About main browsers Protractor can connect to Saucelabs as well.
http://www.saucelabs.com/
And they have 301 different Device/OS/Browser Platforms at now. https://saucelabs.com/platforms
Selenium is certainly the most widely used test automation tool that meets your requirements. I personally used Sahi most of the times which does the same but afaik has no grunt integration.
Related
I have a page built-with angular functionality,
It is works fine from xampp server (http://localhost/...) but It didn't work from my desktop.
Please let me know AngularJS work from client-side like HTML / Java Script.
Yes, AngularJS (v1 and v2) is a JavaScript framework which only works on the client side.
https://angularjs.org/
For the Server side, you can take a look at Node.JS which works perfectly with AngularJS.
https://nodejs.org/en/
Yes, it works on client side. However, you need to install webserver, to run the app. Take a look at node.
Yes, Angular JS works on client side but you can't call REST API Services without Server.
AngularJS fits the definition of a framework the best, even though
it's much more lightweight than a typical framework and that's why
many confuse it with a library.
AngularJS is 100% JavaScript, 100% client-side and compatible with
both desktop and mobile browsers. So it's definitely not a plugin or
some other native browser extension.
About the client side browser support
We run our extensive test suite against the following browsers: the
latest versions of Chrome, Firefox, Safari, and Safari for iOs, as
well as Internet Explorer versions 9-11. See Internet Explorer
Compatibility for more details on supporting legacy IE browsers.
If a browser is untested, it doesn't mean it won't work; for example,
older Android (2.3.x) is supported in the sense that we avoid the dot
notation for reserved words as property names, but we don't actively
test changes against it. You can also expect browsers to work that
share a large part of their codebase with a browser we test, such as
Opera > version 12 (uses the Blink engine), or the various Firefox
derivatives.
Starting to investigate JavaScript testing frameworks (e.g. QUnit, Jasmine, Mocha etc).
I will require our Developers to be able to follow a TDD/BDD approach, so ideally they will be able to run the tests in Visual Studio (using for example Chutzpah). In addition, the tests will automatically run when the solution is built (Release mode) and on the build server.
However...
Our product is used by many people and we can not control the browser that they use. However, we would like to state that our product will definitely work for various browsers (e.g. Chrome, FireFox, IE) and even for specific versions (e.g. IE 8 => Edge).
That being the case, I'm not clear on how we can take our suite of JavaScript tests and run them for each browser engine. Is this possible? If so, please do let me know how.
Thanks
Griff
Typically, TDD is done using unit tests rather than UI tests. Even if you can prove that these pass in multiple browsers, it doesn't prove that the application works in multiple browsers, just that the JavaScript does what it is supposed to in multiple browsers - it doesn't take into account the HTML or CSS.
Although there is some value in checking that your unit tests pass in multiple browsers, UI tests can go further and show that the tested functionality at least "works" in different browsers and most UI testing frameworks will support running in different browsers.
However, in my opinion, to back up the statement:
we would like to state that our product will definitely work for
various browsers
You really need to manually test in those browsers as in my experience the problems that you see between browsers are typically visual.
We got a Cordova App running and wrote ourselves a build script using Grunt which makes building the App a breeze. We don't require any of the APIs Chrome offers and are, apart from some performance issues with elderly Android devices which forced us to block some minor features on those devices, pretty much satisfied with the current status of our app.
So far we couldn't find any reason why it would make sense to transform our Cordova App into a Mobile Chrome App. Or is there something we're missing? Are there any differences in terms of JS speed, CSS support, etc.?
The primary motivation for Chrome Apps on Mobile leveraging Apache Cordova was to bring Desktop Chrome Apps to Android and iOS.
However, there are some reasons why you should/shouldn't consider using the cca toolkit, particularly if you already enjoy using cordova:
Chrome Apps APIs
If you wish to leverage some of the useful Chrome Apps APIs which we have ported to mobile, you may already be able to use them inside your vanilla cordova app, even without using our cca toolkit! (We went out of our way to try and make this work whenever possible, giving back to the community that helps us in turn).
However, for some of the APIs, you really do need to use our cca toolkit, since we may rely on the chrome app lifecycle or other specifics. (It seems our docs don't yet make this distinction clear, so I've filed an issue to address that).
Verdict: consider cca if one of the Chrome Apps API's which do not work on vanilla cordova appeal to you.
Desktop Platform
Chrome Packaged Apps run on any desktop platform chrome runs on -- which is every single mainstream Operating System in popular use today. The capabilities and native integration of these apps are rapidly improving, and are truly removing barriers to using web technologies for whole ranges of application types.
So, while the motivation for Chrome Apps on Mobile was to enable porting some of those desktop apps to mobile, you should consider if the reverse isn't actually useful for you!
This would mean adjusting your existing app to use the chrome app lifecycle and manifest, adhere to restrictions like CSP and disabled web features, and cannot rely on cordova extensions -- but in practice this is often not prohibitive for a cordova app which is already a package offline-enabled web application (thats the hard part)!
Verdict: consider cca if you would also like to also target the desktop platform, or would like to submit your app to the chrome web store.
Cordova Plugins
If your existing mobile app already leverages some cordova plugins, you can still use the cca tool, since we create a fully compatible cordova project. This comes with the caveat that those plugins will only be available on mobile -- but you can use feature detection for desktop-mobile app compatibility.
Verdict: the cca tool does not prohibit the use of cordova plugins.
Mobile Platforms that are not Android or iOS
We do not currently support some of the platforms which vanilla cordova does, such as BlackBerry, Windows Phone, or upcoming platforms like FirefoxOS, Tizen, and Ubuntu (though many of those do not yet have feature parity with Android / iOS anyway).
Verdict: don't use cca if one of these mobile platforms is important to you.
Final Words
If you are already happy with what you have, well, they say that if it aint broke, perhaps don't fix it!
I am thinking of building an application, kind of like TiddlyWiki in the sense that everything is self-contained in an HTML file, or at least in a bundle where a user won't have to install anything. It works on just about any browser, and on mobile phones (Android and iPhone), and in some browsers (e.g. Firefox), manages to save to the local filesystem without a plugin (albeit, it launches many security warnings, but there are other solutions for that). Other browsers happen to use a Java plugin to bypass this restriction.
Are there any technologies that exist that make this possible? HTML5's web storage sounds like it would be almost perfect, except that the data would be tied to the browser.
Any assistance would be appreciated (even if that just means editting / retagging the question to get more folks looking).
Whats about the fileapi: http://caniuse.com/#search=fileapi
I am just adding a relevant comment with this but not exactly an answer...
When you are saying that you want to develop application which contains everything... Then I would like to add about Titanium, PhoneGap, and others (Corona)...
This softwares provides JavaScript base which will be running on all the mobiles (if mobile applications), desktops (if desktop applications) and so on.... But Titanium (as i am working on it) works on the SDK of all the other languages for development...
Now TiddlyWiki, what i have understood from the link is that it is creating a web application or something like that which will work on all the other mobile devices. But this is NOT Good always, Since some application needs to be a NATIVE environment (which is supported by Titanium). Native applications will be much more faster than any other developed applications..
Are where any good frameworks for automated testing HTML5 apps?
I'm now writing an app which should work offline in iOS Safari and it would be awesome if there were some automated testing tools. I have no idea how to test cache.manifest properly, for example.
I'm using Backbone.js, by the way. That would be even better if the tool relies on it or interacts with it in a good way
Answering by listing a link is not always the best way to go, but hey someone did the work before me: http://tinnedfruit.com/2011/03/03/testing-backbone-apps-with-jasmine-sinon.html
Jasmine.js to test
Sinon.js to mock