i have to Test a Vaadin application with cucumber and Selenium web driver(using Java script Executor).is it a good approach for vaadin application Testing?
Yes, You can use Selenium and cucumber but you need to manage your framework to handle multiple windows and using Event firing and event listener classes.
My understanding of Vaadin application in which a UI is a viewport running in a web page. A web page can actually have multiple such UIs within it. Such situation is typical especially with portlets in a portal
--So your framework or test should handle multiple windows.
-- Need to handle Vaadin Sessions.
Vaadin follows an event-driven programming paradigm, in which events, and listeners that handle the events, are the basis of handling user interaction in an application
You need to have good knowledge of Selenium to automate Vaadin
It is possible to test a Vaadin application using only Selenium. However, it might be better to use Vaadin TestbenchVaadin. Testbench is based on Selenium, but provides better integration with Vaadin. The main advantages are:
1. There is no need to provide manual delays between actions, because it waits for UI Components to load.
2. It provides additional selectors to select Vaadin components.
3. It can provide screenshots of failed tests.
The only downside is that Testbench is a commercial feature that requires you to pay money.
For a more detailed analysis of pros/cons is see: Official Blog Entry
There is a Github repository that shows a basic setup of testbench as well as plain Selenium.
I used to have same problem, and I used the Selenium IDE for identifying the XPATH for each element in vaadin, then use it like this:
driver.findElement(By.xpath("//div[#id='thalamusboapp-218829419']/div/div[2]/div[3]/div/div/div[2]/div/span/span") );
Related
We are planning to migrate our Silverlight application which having both business and UI logic to new technology. Is there any standard procedures or tools available for silverlight migration.
We want to move to standard technology like html and supported by all windows/mac/Linux browsers. Please give us any suggestions
There is no straight-forward migration path from Silverlight to any technology, despite probably to WPF to a degree, but as you mentioned that you want to run in the browser, probably the best way today is to use Blazor, which just got its first official release, and Microsoft is heavily investing in it right now.
On top of that, the French company Userware created the OpenSilver platform, which is a Silverlight replacement based on WebAssembly and Blazor, compatible with all major browsers. They even provide professional migration services based on this approach.
There is also rich ecosystem already evolved, with a lot of third-party UI components vendors (like Telerik, DevExpress, Radzen, etc.).
At Mobilize.Net we have a migration tool that converts the client side XAML and C# to TypeScript using Angular, Kendo UI, HTML, and CSS. It supports C# constructs like generics and interfaces.
You can watch a live stream from Twitch here This is an approach most suitable for very large complex SL web apps that would be too time consuming or expensive to rewrite into a pure native approach.
AEM itself is self reliant WCMS and can be used to generate very rich digital experiences over multiple channels.
Often there is talk of using Angular as front end and moving AEM to backseat. What is point of doing so?
Using angular will add additional complexity and developer has to deal with it, increasing efforts for building system.
It will undermine core AEM features e.g. HTL & clientlibs
Multi channel experience can still be achieved without angular.
In short: there is no point in doing so when you deliver static pages, as seen in standard AEM use cases. It get's even worse: when you want to use AEM for dynamic pages, you might run into performance issues, so an external data source / index to query the "dynamic" data is almost mandatory.
I would recommend a clean separation of view and view-model using Sightly and Sling models which allow for a fast refactoring of views in case there is a good reason to migrate the frontend to a different technology / templating language.
And I am leaving out the fact that Angular will be basically replaced by Angular 2 and there are strong competitors like React, Ember etc...
AEM's core strengths are:
WYSIWYG
Multiple Adobe suite integration (analytics, target etc)
Authoring experience for MSM
Security integration from UI to db layer
There are many more strenghts along with many weaknesses. Using Angular or other similar platforms require AEM to be used as Content as a Service (CaaS) which isn't its primary strenght yet.
Organizations that invest in AEM are mostly after the core strenghts provided by it and won't normally benefit from using AEM as a CaaS platform. Unless Adobe provides plugin model for their integration suite that can work with mainstream front wnd technologies like Angular (2) and React, it would be a very uphill task for any team to get the most out of AEM suite without missing out on all the benefits provided (at a cost) by the whole of Adobe marketing suite.
In short, from TcO perspective, these platforms are not easily compatible with AEM due to the unique nature of product which means the integration is normally a challenge and sometimes counter productive when integration benefits of the core platform are compromised.
I believe it totally depends on the use case. I have done projects with AEM using jQuery and others using Angular. If developer knows what he/she is doing, adding angular is not much of a hassle. 2 way data binding, a clean way of doing Ajax and ease of Single Page Application, that pretty much sums it up. Works really well..
Angular and other front-end frameworks provide the additional benefit of SPA which if integrated the right way with AEM can work wonders!
Yes, I agree that integration is an uphill task but the page load times can reduce significantly and using features like routing we can reduce the server calls for transition across the site pages.
Why AEM-Angular integration can be a good thing?
AEM can be used as a CaaS platform in few cases where the content will primarily be loaded using SPA. In other cases, components can be a mix of HTL and Angular where HTL can provide additional security using proper context.
You can pass AEM authored content to Angular directives/components as attributes and perform the desired functionality.
Angular can be used to build reusable components and directives on the front-end which can simply be reused across AEM components.
The Angular dependencies can be made a part of the AEM client library and this ensures that Angular functionality works as expected.
Build tools like Maven and Ant are powerful enough to support the integration. Simple tasks have to be written in pom.xml.
AEM 6.4 Beta has support for front-end frameworks and I have observed how fast the content load can be!
Other AEM integrations (Adobe Target, Adobe Campaign, Adobe Analytics) can be still leveraged in similar ways as before.
Did I forget JQuery? Angular and other front-end frameworks will provide cleaner and more efficient ways of doing the same things in JQuery.
The decision to use both will totally depend on the use case and this is not recommended for all solutions though.
I have worked on AEM for more than a year. In my project, the stack was AEM, jQuery, and some 3rd party library to handle JS relevant issues(like IE support and util functions).
If you want to integrate Angular then I see the below things from your query
Good :
You don't need the headache of java related issues.
No need for more backend developers(though I am a backend developer).
If you do want to change some files in stage or prod environment, no need to go with java change directly package installation will work.
You can leverage angular strategies to build your project efficiently.
No need to worry about your project optimization. Angular will take care of JS library optimization and loading into client-side browser.
No need worry for page speed issues from google audit for your websites. That will be taken care of by Angular.
You will be able to achieve the hybrid model of clientlib and can avoid lot's of Js issues along with clientlib comes in to picture.
Testing of components will be easier.
AEM also follows Component similar to angular, so things can be merged based on good architecture.
Not Good:
sightly syntax might be underutilized.
Still, there will be cases you have to dependent on java for achieving some features.
Security issues need to be fixed as everything will be done on the client-side.
more issues if you are using etc/map related URLs.
more complexity if you follow SEO optimization standards.
More dispatcher configurations.
Needs to habituate aem structure with angular structure.
AEM structure will be more complex when merged with angular
I am quite new to Angular. I have written this answer based on my experience. I will keep updating if any edits required.
Using AEM as an integration layer is a challenging decision. AEM is a content management system and works well for static content (content is cached at Dispatcher layer).
However, it use the Jetty server under the hood. Jetty uses thread pools for handling requests. It means that when the number of users increases, it use more and more resources. The situation is the same for time-consuming operations - think about API's unavailability or delays.
Instead of using AEM as an integration layer, you delegate this integration logic to more reactive systems such as Knot.x. Then AEM may serve only static pages (templates), Knot.x would fill all required data from external APIs.
See more here.
I am looking for automated testing tools to test a webpage heavily written using ExtJS. Initially I was using casperJS/phantomJS. Since, those tests work best in a CI environment and are super-light and easy to code. But I found a limitation that casperJs does not support TrifleJS for IE testing. It only supports phantomJS(chrome and safari) and slimerJS(firefox).
I need to test our web-app on IE9, IE10 and IE11 too. Squish seems to be very flexible and well-developed. I want to know whether it is suitable for testing the ExtJS web-app.
Thanks
According to the matrix at this link Squish does support ExtJS framework. Of course main problem of testing ExtJS apps is that all the element IDs are dynamically generated and one cannot rely on these for UI testing. However Squish provides XPath-based search that can be used instead.
I'm actively evaluating Squish for our ExtJS 4.2.x based web app so in a while if you interested I would be able to provide more insights but it does look very promising especially since you can use Eclipse-based plugin to build your tests visually
I was a .net based windows application developer and being a web developer now.
For the last couple of years, I tried to follow principles of Specification by example in a project.
On the last project I was involved, our team used WPF with MVVM(Model-View-ViewModel) pattern and I tried SpecFlow for testing. (Well.. the coverage by SpecFlow was very low though cause it was not officially adopted from our team and I couldn't spend enough time on it.)
Now our team started to migrate the existing windows application to a web based application and decided to use cucumber.js as a tool for implementing 'Specification by example'.
When I was trying SpecFlow before, I made all the step definitions to test ViewModel layer instead of View and it was the only way actually. What I'm confused with cucumber.js is that most of examples demonstrate how to test features via web browsers(headless or real ones).
If the features are specifying specific ui behaviors then accessing a DOM element and evaluating its value make sense. However, as far as I learned about Specification by examples, testing under the UI layer is recommended instead of UI elements directly.
It seems like most of modern web applications have layers such as MVC, MVVM(knouckout.js) nowadays. Our web application will use Angularjs and this is my theory.
I guess it is possible to use feature files - which do not state any specific UI controls and behaviors - to test under the skin of UI layer, without relying browser support. That layer would be Model of angularjs, not ui elements.
Is this approach missing something or wrong with cucumber.js?
Please give me some insights and correct me if I'm wrong.
Thanks in advance!
Specification by example specifies requirements by giving examples from the point of view of the user. What's more representative of the user: clicking items on a web page, or directly calling code? A user won't be calling methods on your view model, so in my opinion a feature test is a much better way to test expected behaviour.
I need to test an angular application and I'm thinking which testing framework to use.
Can someone please list the differences between those 2 testing framework, what is good / bad in each. when should each of them should be used? can the one replace the second?
Edit 1:
I'll try to focus my question. what I'm really interested in is the technical abilities of the 2 frameworks.
for example, some of the differences I have found:
selenium webdriver has the ability to run on grid in parallel on multiple machines, on the other side, angular scenarios runs much faster than selenium.
with selenium I can use keyboard keys such as Enter, Backspace and more and also do drag and drop actions.
selenium is not dependent on the app technology, angular is for angular apps only
Those are the type of differences I'm looking for - what can be done with one and can't be done with the other
thanks
Both should be used for testing an angular application. However, in my experience, they serve different purposes.
Angular e2e tests are your best friends when integrating new features into your application, or changing already existing features. They are there to make sure your application still behaves as expected if you are making changes to your code. These tests are much faster than selenium, do not need to be as in-depth, and, in my experience, are best executed before you push a new feature to your version control server.
Selenium tests should be used for regression testing. These tests should be far more in-depth than Angular e2e tests, and should be performed before pushing code into production.
UPDATE: This question may be less relevant now. As of January 2014, Angular plans to move from their own E2E suite to the protractor library for function tests, which use Selenium Webdriver.
If you're starting a new Angular project, you may want to look into using Protractor, as it is going to replace the current method of E2E Testing in the near future.
(Source: http://docs.angularjs.org/guide/dev_guide.e2e-testing)
I am struggling with this question as well.
Here is my thinking today:
1) Use Angular e2e testing for integration/regression testing the UI with mocks of your external dependencies (like the app server).
2) Use Selenium for integration/regression testing the complete system in a test/qa environment.
It seems Angular e2e testing helps fill in the gaps that unit testing leaves in testing view and controller logic that is tied to UI events. All of the Angular tests should mock external dependencies.
Selenium seems like the best fit for testing the entire system as the user will experience it.
This is such a subjective question, and therefore I'd first tell you to do some research. There is not much difference.
It is a very new project, whereas Selenium is a lot more mature. For instance, the JSON Wire Protocol that WebDriver is built on top of, is an actual W3C spec. This shows the project is very mature and very stable.
Due to the above, Selenium has a much much wider set of documentation, and a much wider community.
With Selenium you have a variety of different languages to use to code the tests in, as well as use the IDE. Angular limits use to pure JavaScript. For a lot of manual testers, this is a skill most do not have.
Both Selenium and Angular are open source, which (believe me) helps tremendously in debugging problems and understanding design decisions in their respective API's.