I have just started to use protractor. I wanted to know it's limitation and specifically if it is dependent on version of AngularJS
I don't complete agree with #Zanon here. Protractor actually relies on some Angular-specific things like getTestability test helper that helps to let Protractor know that Angular is stable, ready and there are no outstanding requests left (source). This is actually what makes Protractor somewhat special and is recommended to use for testing Angular apps - the test flow becomes more natural, there is usually no need for extra waits - Protractor just works in sync with Angular application under test.
To answer your specific question:
for testing Angular 1.x apps - you can use any Protractor version
for testing Angular 2.x apps - Protractor >= 2.5.0
No, Protractor is not dependent on any specific Angular 1.x version.
However, since Angular 2.x added big new and breaking changes, you need Protractor version 2.5 (or later) to use it (you can confirm this here).
Protractor is a Node.js program that uses browser drives to execute tests as a real user would. It was designed thinking on Angular workflows, but it doesn't use Angular code, so its dependency is by design choices and not on specific code versions.
Related
In nearest future I will be doing a serious update of the application. I have a little experience with ember.js & have no one who can help me resolving this matter. The app is written in ember 1.12, and there are few dependencies. It has a web version and mobile (iOS+Android) written in cordova - all of them need an upgrade.
What kind of problems should I expect?
How to prepare for them?
How much time should I estimate?
Any help will be very useful- it's first time when I will be doing app upgrade.
I have checked this links, but most of them are for above 2.0 versions.
https://www.emberscreencasts.com/meta_guide_to_upgrading_ember
https://medium.com/ingenious/how-to-upgrade-ember-js-to-3-x-and-live-to-fight-another-day-cfc28c16b726
http://www.ember-cli-diff.org/
https://medium.com/front-end-hacking/everything-you-need-to-know-to-upgrade-your-ember-js-app-including-ember-3-9de5e808dde0
https://medium.com/ember-ish/upgrading-ember-from-1-13-to-2-8-0-f1dbcecc40ca
https://medium.com/front-end-hacking/how-to-use-ember-2-code-in-your-ember-3-app-9ed15c28bad6
Depending on the size of your application and how extensive your test suite is, you'll probably be dedicating a minimum of 4 weeks getting just the web version up to 3.5.
The process will be time consuming and tedious.
1. Upgrade by 1 minor version (1.12->1.13)
2: Run your test suite and fix any issues that come up
3: Manually test the tool by navigating around & fix any issues that come up
4: During the testing, you should have identified a handful of deprecations. Fix those.
5: Repeat steps 1-4
6: After you've upgraded to 2.0.0, you may be able to skip a couple of minor versions at a time, if you aren't using private APIs and your dependencies are small.
Ember maintains their [changelog](
https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md) as well as a page that lists deprecations and their solutions, so you'll want to become buddies with the version you're upgrading to. For each deprecation they mention, check the linked issue history to see what the suggested replacement is. Be proactive - don't wait until the final version to fix a deprecation.
The big/common issues you'll encounter are:
Views are deprecated and removed. You'll need to understand how components work and migrate any existing views to a component.
The select helper gets removed.
If your views & components use targetObject to get the controller, you'll need to make them work without doing it. This means determining what properties & actions need to be passed in and explicitly doing it. Components shouldn't know anything about what called them.
Ember has a solid guide on working with deprecations at https://guides.emberjs.com/release/configuring-ember/handling-deprecations/ that may be of some help.
Keep your changes versioned. You'll break something bad enough that it's easier to just roll back and try again. If you're not using versioning, you're in for a really hard time.
Finally, make sure you clean out your npm directory between versions & wipes - If you don't, you may thing everything is working, but it really isn't.
As Patsy commented - You're probably better off hiring someone who knows ember very well to do this upgrade. If you don't know ember very well, you may be putting fixes in that back you into a corner.
I upgraded a bunch of Ember apps / addons from 1.11 -> 2.18 in advance of the 3.0 release. I don't think there was a single minor version upgrade until the 2.10s that didn't break my app.
I also simultaneously upgraded ember cli with the app. I tried upgrading ember cli to the latest, but I had a bunch of cryptic errors and reached a sort of dead end. What I instead opted for was looking back at the Ember release notes and seeing which version of ember cli was the latest at the time of the Ember release. I would upgrade Ember cli every 4 versions or so, unless if I encountered issues at which point I would immediately upgrade.
The single most important thing is automated tests. I see that you say you have no tests and will just manually test but this is foolish. I had a bunch of code that I needed to upgrade that had no tests. I wrote comprehensive tests over the course of a week since I had two weeks to do the upgrade. These were absolutely vital and some upgrades would break 60-80% of my tests. It would have taken me 2 months without tests probably, but I accomplished it in 2 weeks with the tests, using the first to write the needed extra tests.
Comprehensive tests are best, but far from necessary. At the minimum I would recommend you take the time to mock your API calls and write an acceptance test for each page of your app that serves as a smoke test. The test is as simple as go to the url and check the dom is there. Ember cli page object helps immensely + html5 test-* data classes.
Once you've done that, follow what #Trenton Trama suggested. Upgrade minor version, run tests, fix problems, rinse and repeat until fully upgraded.
I kind of think that answer of this question would be No by going through Protractor issue 1798 and Protractor vs Webdriver-IO comparisions.
I want to write automated tests cases for a hybrid mobile app in JavaScript which will run on Appium.
Currently I have both Protractor and Appium configured in same project to run those End-to-End test cases, and they work.
Problems are that,
I have to write separate test cases for each of them.
Cases should also work on mobile devices(Android and iOS) and protractor doesn't support native apps tests.
Situation is, I am more comfortable with Protractor's settings in my current project than Webdriver-IO which Appium uses (just a personal preference).
Question-
Is there a way of using only Protractor while writing test cases which would work using Appium and work perfectly on Devices/Emulators?
I am also open for any suggestion(s).
If answer remains No, I will change my codes to only use WebdriverIO in order to keep my test cases reusable and only once.
The answer is still NO protractor currently does not have support for mobile native apps but you can use it for automating browsers in your mobile.
Better use WebdriverIO but it also has its own limitations, please do check its changelog and github issues before deciding it as your webdriver framework.
Question
In terms of e2e testing, what can't we do with Karma and JQuery that is possible with Protractor?
Explanation
I'm currently building a testing framework for my JavaScript application.
I'm using Karma for Unit Testing and Protractor for E2E Testing as suggested by many people.
I'm aware of the conceptual differences between unit testing and e2e testing, but, in the context of JavaScript, I don't clearly understand why we need framework like Protractor.
As far as I know, the point of e2e testing is to use the application as a simple end-user. For that, tools like Protractor use a webdriver to interact with a browser and let us simulate some user events (clicking on element, filling forms...).
The thing is, why can't we simply do this by using Karma and JQuery?
Indeed, JQuery comes with lots of methods to interact with a DOM element (trigger event, get/set element's property, set value to an input...). Furthermore, it provides selectors which make the selection of DOM element very easy.
From my point of view, Karma and JQuery has (almost) everything needed for e2e testing (if we don't take care of the browser's window's operations available in Protractor which enable for example to set the window size or location).
I'm obviously missing something, any clarification will be helpful.
Using Jquery and Karma the way you would, is a behavior-driven-test but not an end-to-end test.
With Jquery and Karma, you can't detect cross-browser issues like you would in protractor. Protractor on the other hand runs your tests as if it was an end-user. It literally opens the browser you want and tests your application in that browser.
What are the differences? What are the advantages of using one over the other for an Angular project?
Nightwatch.js vs Protractor
If you are working on an AngularJS project, the choice is simple - Protractor:
it is being made specifically for angular apps (though it can be used for non-angular apps also)
supports angular-specific locator strategies (like by.model, by.repeater etc)
waits for angular to start up during the page load (sync)
it is being actively maintained and improved mostly by google developers with a close cooperation with an angular team - this means that protractor follows the angular release cycle and new changes
There are a few more differences that weren't laid out in the top answer.
The big one for me is, as of now, protractor doesn't support phantomJS (http://www.protractortest.org/#/browser-setup#setting-up-phantomjs). I planned on integrating automation in to the CI system, but with protractor I would have to set up a windows VM to run the tests.
Other benefits of nightwatch:
Asserts are done automatically.
Clean console output, you could hand
off to anyone.
Test reports are automatically generated and saved to a /reports directory.
Protractor pros:
The angular-specific locators that protractor supports is very powerful and could help immensely with creating stable tests.
WaitForAngular is also very helpful.
EDIT:
Since the time I wrote this comment and present day our team has happily switched over to using cypress.io. If you are deciding test frameworks I highly recommend checking it out: https://www.cypress.io/
I'd like to know if there is anything underlying jasmine-jquery like a browser engine or something that it uses to simulate HTML stuff?
Of is it just a self written DOM Model? Is it even a DOM Model?
The reason for that question is that i need to know how reliable tests are written with this fixtures. Can they / should they be used with a whole application loaded into the fixtures for unit testing the application?
How can they be compared to the behaviour of different browsers? So does it behave more like Chrome, Firefox, or even IE6 or is it a custom implementation of the W3C Standards?
Unfortunately i wasn't able to find anything about this. Maybe it's to obvious?
Check out the Karma project. It runs your jasmine tests in real browsers, so you don't have to worry about it.
I'm not sure what engine jasmine uses to power its DOM, but you are better running your front end tests in real browsers.
For node script, use jasmine_node.
Good luck.
Tl;Dr: The fixtures are simply appended into a div with an id of jasmine-fixtures as defined in the jasmine.Fixtures constructor.
You can check for yourself:
fit("See fixtures",function(){
setFixtures("<h1 id='ahoy'>Hello World</h1>");
expect($("#ahoy")).toExist();
alert($("html").html());
});
In your jasmine.jquery.js dependency the code is really clean and easy to follow, check the following methods - Fixtures,addToContainer_,createContainer_
As a sidenote - we currently successfully adopted Jasmine which allows us to follow TDD in a front-end ES5 + jQuery project I am working on. It is a very similar experience to what the test setup of the create-react-app ships with.