The application under test is built on angular because of which the xpaths are failing to locate the element . I am using selenium web diver for automating the tests and google chrome browser.
Can anybody kindly specify how to break down angularjs components to basic html elements while creating the xpath or any other way i can adapt to find the exact element on the page.
Any link or path or tips to follow.
I have searched a lot but no luck till now.
Starting with covering some general concerns.
When testing AngularJS applications, the timing issues are usually the most common - this is partially why we have tools like Protractor built mainly to test AngularJS applications. What makes it unique is that it works in sync with Angular, knowing when it is ready to be interacted with. It also provide AngularJS specific locators which makes locating elements much easier, samples:
element.all(by.repeater("item in items"));
element(by.binding("mybinding"));
element(by.model("mymodel"));
If you can, you should consider switching to Protractor - the test flow is natural - almost no explicit waits, a lot of convenient syntactic sugar and much more element-locating options.
If not, you can still use Angular-specific attributes to locate elements, examples:
driver.findElements(By.xpath("//*[#ng-repeat='item in items']"));
driver.findElement(By.xpath("//*[#ng-binding='mybinding']"));
driver.findElement(By.xpath("//*[#ng-model='mymodel']"));
Though, as usual, you should prefer to use ids, classes and other "data-oriented" attributes.
Things can easily go wrong with the above sample expressions - imagine web developers add a "tracking" to the repeater, or rename the ng-repeater to data-ng-repeater.
As a side note, using Angular specific things like ng-* attributes in your tests, would make the test codebase tight to this specific technology used to build the application under test. It is not necessarily a bad thing but you should keep it in mind.
Related
I have seen many articles regarding the changes in Angular2 . But I can't find much advantage in using Angular2. Can some one point out some new things that can be done using Angular2 which can't be done using the previous versions.
I know there are changes like $scope changed to this. I'm not asking for changes. I'm asking for new features that is in Angular2.
The TL;DR Version
Because ES6 is important to pick up, so no need for a custom dependency management system anymore. ES6 and Angular 1 together get ugly fast, as they together introduce a bajillion coding styles :(
Although the library is overall heavier, the architecture it uses (all component based) is a lot faster, lighter, and modular for a scalable application. See http://info.meteor.com/blog/comparing-performance-of-blaze-react-angular-meteor-and-angular-2-with-meteor
You receive (upcoming) Server Side Rendering, which enables fast initial load time and Search Engine Optimization (Yay!) See: https://github.com/angular/universal
You receive WebWorker friendliness, which makes your application able to "multi-task". See: https://github.com/angular/angular/blob/master/modules/angular2/docs/web_workers/web_workers.md
Shadow DOM is not fully inherited by Angular 2 yet, but I'm sure it will be. It has some support right now.
The whole concept of $scope is gone. You receive two way data binding with anything you put in your ES6/TypeScript class, but anything more you need to create a Observable or promise. Unfortunately, you can't just shove anything into the scope, digest, and WALAH! anymore.
And of course, all the cool stuff they mention on their website: https://angular.io/features.html
Hope that helps!
Support for different languages TypeScript, Dart, ES5, ES6.
Change detection is much more effective
Support for isomorphic applications where the same code can run on the server, the browser and a WebWorker in the browser
Moves more work to build time to reduce the time for the initial page load.
Simplified binding syntax
Improved DI
There are also lots of mostly smaller and tiny features that Angular2 doesn't (yet?) support which Angular 1.x does.
I know that polymer is primarily used to create reusable elements, and angular is supposed to be used to create web apps (at least from a "high level" perspective), but I wonder, since you can wrap your own "Screens" as polymer elements, which actually could serve as controllers too, and switch the active page with the iron-pages element (see SPA demo), and you can also use more-routing well... instead of "routing by code", it supports one/two way binding and events, I've actually done some small SPA app like that myself, and so far so good actually! moving on-
Assuming I don't care about having some built-in REST wrapper such as the one provided by Angular (Easy to roll up my own if I use Dart), then in Dart's case:
Could polymer actually be used to create full apps?
Would it have any implications in performance if my whole app is in polymer? by that I mean, every screen is really an element, and so on.
Development speed, maintainability, and experience? (considering the fact that I use Dart which helps a lot in these areas)
Overall, is it a good idea? I'd like to know your opinions.
Any companies/indie devs have done this before? not necessarily with Dart, but with TypeScript/JS as well, although I'm 100% set on Dart.
I think Polymer is quite a good fit for that. I wouldn't necessarily go for "a Polymer element per page" but that might depend on the kind of application you are going to build. Especially in Dart Polymer it's a good start to make the root Element a Polymer element. You can for example keep the navigation and switch only a part of the view instead of the entire page (but that might be what you had in mind anyway)
You can also use dependency injection, which is a strong point of Angular.
The dirty checking might be better in Angular 2 but Angular isn't released yet and Polymer also has plans to improve here.
I have a relatively big web app is written in AngularJS. Our automation is using Ranorex to run BDD tests.
We are in a constant dilemma on how to enable the Ranorex tests to find UI elements effectively. Currently we're mainly using a custom attribute for it, testid (e.g. <div testid="done_btn">), but in some cases it performs very poorly, not sure whether it's because the querying XPaths aren't optimized or some other Ranorex configuration.
Using the id attribute is way faster but it just doesn't feel right to use it for automation. Besides, keeping it unique might require some coding in some cases (e.g. when using ng-repeat).
Is using id just for automation purposes OK or is it a bad practice? Why?
Any way to make Ranorex relate to custom attributes such as testid differently so that it'll be found faster? I've read about Ranorex Weight Rule but couldn't find a way to define custom attributes.
The quick answer: YES! Use the Id's.
I'm not actually familiar with the dilemma you are facing. Can you please further explain the reasoning behind not wanting to use the id-s.
And if you face issues related to id's not being unique in some cases you can combine different elements to the path (eg."#id='save_btn' and #innerText='Save'").
Usually if you can improve the speed and stability of your automation with no visual or functional expense - do it.
I'm working on a project which has the luxury of using ECMA 6 on the latest browsers for a product that will be shipped in 1.5 years. So we thought why not use Web Components now that Angular 2 isn't available (which is going to be ECMA 6). And while we are at it, can we replace Angular altogether without having to go back to stone age?
How to replace Angular?
There's this site called youmightnotneedjquery.com which is basically about how modern browsers actually have most of the stuff that jQuery was traditionally used for. I'm interested to see something like that for Angular.
We mainly use four Angular features. What are my options for replacing them?
Angular Directives --> Web Components
Angular Modules --> ECMA 6 Modules (not exactly the same thing)
Angular Routes --> ???
Angular 2-way databinding --> ???
PS. We don't want to replace Angular with something similar like Backbone or Ember. We want to replace it with standard web technologies but if we have to use small tools to fill the gap, we'll consider it.
I've been researching in the past 3 weeks and turns out many people are thinking about an alternative after Angular took a drastic change path. Fortunately the upcomming W3C Web Components standard actually has all we need and it works right now with polyfills from the Polymer project. So to answer the question:
Angular Directives --> Web Components use the polyfill until all browsers support it.
Angular Modules --> ECMA 6 Modules part of the problem is solved with HTML imports. But you can also use Traceur until the browsers support it.
Angular Routes --> There's a component for that™ use <app-router>.
Angular 2-way databinding --> Polymer adds a "magic" layer on top of the plain standard web components. This includes many features including data-binding.
+Plus More
If you're wondering about the build process for concatenating files in order to reduce the number of HTTP requests, take a look at Addy Osmani's post about Vulcanize. Spoiler: you may not need it with the upcoming HTTP 2 optimizations.
Many Angular projects use Twitter Bootstrap for the layout. Polymer can do that plus it plays nicely with Google's Paper elements (totally optional but superbly awesome).
If you want to make yourself familiar with web components in general, here is a bunch of nice articles: http://webcomponents.org/articles/
And here is a wealth of web components: http://customelements.io/ I don't know if it's going to be a new NPM, but the list components is pretty impressive and growing.
It's relatively complicated to expose an API for an Angular component. People have come up with all sorts of methods from link function to emitting events. In Web Components, however, it's really easy to make your component interact with the world outside and indeed the API and events you expose aren't much different from standard HTML tags like <audio>.
Just like Angular, you can use Polymer with Dart as well.
Conclusion
Overall, I don't see any reason to use Angular except if:
You have a huge source code investment in angular and don't want to port everything to standard web. (Angular 2.0 will deprecate your code anyway, so you're stuck with Angular 1.*)
Your team is too lazy to learn a new technology (in that case web might not be the right platform for this attitude anyway).
Angular was good for what it was doing and had its own Hype cycle. Web components solve many of the issues Angular was trying to address. Probably Angular had a role as a proof of concept for the Web components. But now it's time to move on. Web is reinventing itself everyday and it's inevitable to moves someone's cheese.
I'm not saying that Polymer is the ultimate answer to everything. At best it's another Angular which will render useless in a couple of years, but now it's a good time to learn and use it. The W3C standards don't die easily though, and Polymer tends to be much closer to them.
There's an element for that™ is the new There's an app for that™
TLDR: seriously consider writing an almost Angular 2.0-compatable Angular 1.3 app before rolling your own framework
It seems as if you've identified that Angular does a lot of things the right way and that's why you're attempting to replicate it, so basically you're going to roll your own by combining a hodgepodge of libraries. Unless you have an enormous investment of Engineering hours, the framework you build will likely be:
Lightly documented
A cross-browser maintenance nightmare and (worst of all)
Difficult for new hires to learn
If there wasn't a framework out there that did what you want to do already, I think rolling your own makes sense, but by trying to recreate Angular you're:
Taking on a lot of Engineering work that has already been done by a dedicated team, that could have been spent on building product
Made it MUCH more difficult to onboard new employees because you have to:
Find candidates that are willing to use a home-grown framework instead of growing their skills at an open source framework they could use elsewhere
Train these employees to use your framework (and good luck unless your documentation is mature)
I know your question asks how to replace Angular, but I've seen too many companies go the route of rolling their own and paying for it down the road. Again, if your budget includes a ton of core resources to build out (and document, and maintain) the framework and you don't think there is any chance corners will get cut when push comes to shove later if timelines get tight, then rolling your own might make sense. However, I think you should seriously consider reading up on how to write Angular 1.3 apps so that they're easy to port to Angular 2.0 and go the Angular route. Just look at the size of the community you're missing out on:
http://www.airpair.com/js/javascript-framework-comparison
What jinja2 can achieve, the same can be achieved with Angular.js. My question is- are there any advantages of replacing jinja2 with angular.js completely ?
I think most problems came from the same obvious difference: Jinja2 is server-side, Angular is client-side, this makes they really different.
SEO. Google don't understand Angular magics. It is just a heavy Javascript code and Google can't understand it fine. Sure, you have some workarounds to show your important text to Google, but to solve it you'll have to render some things server-side, going back to Jinja2 or some hack to render things to improve your SEO. (it is not important if you don't care about Google searches)
Performance Server-side rendering is way faster than Javascript rendering. I'm talking about your average user, maybe with an outdated Internet Explorer and a crappy internet connection. With Angular, you have to wait at least some Javascript assets to be loaded before the page is usable. Users notice this and we know a slow site will hit your conversions. Check this Twitter article about "time for first tweet": https://blog.twitter.com/2012/improving-performance-on-twittercom
Compatibility. Yes, they claim the framework supports all common browsers, but have full documentation about hacks to make it work for IE7. Depends of your audience.
Maturity. Jinja2 is really stable, has a pretty API and is deployed with almost all Flask websites. Angular is still evolving and sometimes things just change a lot.
Inexperience. You can't just replace Angular with Jinja2. When you try it, you will understand they are different and you must not work the same way with both. You will make a lot of mistakes before you make things right, just like with any new awesome tool you use.
Of course you can claim against all my arguments based on your specific needs, this is just some things you must understand before you go to Angular.
That said, I'm using Angular in several projects, mostly for single page apps. This is an awesome use case for Angular. In all these projects, I still use Jinja2 to some rendering, so this is not a complete replacement.
UPDATE:
Some updates almost two years after my initial response.
Google is better understanding dynamic rendering, but I still don't trust it.
I don't think the client-side rendering is a thing. Only realtime data is rendered client side, but the base HTML is generated server side.
Angular dropped IE7/IE8 support. It is definitelly a good thing for the web, but unfortunately I still must support these browsers in some cases.
Angular 2 is on the way, changing everything you know about current versions. I don't remember any major Jinja2 change.
Why is replacement your objective? Use the power of both Jinja and other server side frameworks together with the power of client side frameworks.
The benefits of using both:
less and easy code
better performance
more easy to maintain
and much more. You have a choice.
Choosing for one or the other will make your work frustrating and complex.