Vuejs 2 v-on:click.prevent() - vue.js

I would like to know what these options people are using more.
1) Using v-on on normal (div, span, etc) element
<div v-on:click="myFunction" class="cursor-pointer">Click me<div>
Here, it requires to have the a class to set up the pointer cursor to indicate that is can be clicked, and also, to increase the UX.
1) Using v-on on link element
Click me
Here, doesn't need to have any classe to set up the pointer cursor. However, it requires the prevent mode to stop the link action.
So, What is the best practice, advantages and drawbacks of these two approaches?

Ultimately, it doesn't really matter. Generally speaking though, you should be writing your HTML dom in Vue.js the same way you would write it without Vue.js. If something should be a link because it's leading to another view in your application, then <a> makes sense. If you wouldn't normally use an anchor link if it was just a static HTML page, then you're probably better to be writing it with a div, span, or whatever your developer instincts decide in that case.
Always try to write your code as if someone else is going to be looking at it, in which case they are going to have some expectation of what an <a> is supposed to be doing.

Related

What is the difference between <router-link> and $router.push?

<router-link> in my opinion takes more work to implement, since you can add $router.push to any element with an #click event.
What are the pros and cons of each approach? Is there any instance, where <router-link> can not be replaced by $router.push?
While router-link's handler does the same $router.push(), it also performs under the hood a handful of useful actions that you will have to implement by yourself to assure the navigation works as expected in every scenario. For example, it activates a "navigation guard" to check for the validity of the triggering event, catches any navigation errors, also, it is the implementation of active route detection and styling which may be a pain to implement in complex navigations (for ex. multilevel navigation menus) that is also simplified by the router-link implementation.
These are some of the pros that I could spot at a first glance at its source code. You can look at it for a more in depth comparison here
First of all is a tag like a tag in HTML so you can not use it inside your script tags. You can only use it inside tags. You have to give to attribute to router-link and you do not need to use click etc.
However, for bigger projects sometimes you need to redirect to another page after you submit a form, or anywhere you like to use redirection in your js. That's why there is $router.push, the $router object is vue-router object so you have all functions that vue-router serves you.

Better way to get a parent element using Selenium

There is this button that when I try to click on, he kinda moves a little and opens a sub-menu. The solution is easy, just click on the div a few levels above him (still the button). But he is always changing class names.
I mannage to do it using this aberation //div[#style]/span[#aria-label]/../../../../../...
I also tried to use //div[#style]/span[#aria-label]/parent::div[#role="option"], but it did not work, and I don't know why.
Does anyone have any suggestions to make it more decent? I am sure that the "../" was not mean to be used on so many levels...
Also, I was trying to use CSS selectors for my entire project, but after spending some hours looking at StackOverflow answers, the solution seems to be use XPATH. If there is a way to do this operation with CSS Selectors, I would be very interested.
You can shorten and make your XPath expression more readable with :
//div[#style]/span[#aria-label]/ancestor::*[5]
where ancestor::*[5] replaces /../../../../../...

Identifying the same Web Elements with Selenium

I am an Automation Engineer, I am currently trying to create test cases for a webpage that are sustainable ( that I can run at a later time and have still pass)
Here is my problem:
I am trying to select multiple web buttons that have the same exact class name. Now I can 'select' these buttons but these are only temporary x paths that are subject to change.
I need UNIQUE ID's (or some way of distinguishing them) for the same web elements. The only difference in the x paths are:
HTML format code that I can find each button, however if one button is moved my tests will fail.
HTML code that is the class name + nth of the button. But again my tests will fail if a button is taken out of the webpage.
//*[#id="tenant-details-accordion"]/div[1]/div[2]/div/div[2]/div[1]/div/a/div
//*[#id="tenant-details-accordion"]/div[1]/div[2]/div/div[2]/div[2]/div/a/div
//*[#id="tenant-details-accordion"]/div[1]/div[2]/div/div[2]/div[3]/div/a/div
^^The above code is how I currently find each button with Selenium
If I copy each classes x path this is what I get
<div class="src-js-components-DateControl-___DateControl__dateControl___2nYAL"><a tabindex="0"><div class="src-js-components-DateControl-___DateControl__icon___2z6Ak null"></div><!-- react-text: 392 -->Set +<!-- /react-text --></a></div>
<div class="src-js-components-DateControl-___DateControl__dateControl___2nYAL"><a tabindex="0"><div class="src-js-components-DateControl-___DateControl__icon___2z6Ak null"></div><!-- react-text: 386 -->Set +<!-- /react-text --></a></div>
<div class="src-js-components-DateControl-___DateControl__dateControl___2nYAL"><a tabindex="0"><div class="src-js-components-DateControl-___DateControl__icon___2z6Ak null"></div><!-- react-text: 398 -->Set +<!-- /react-text --></a></div>
I have talked to the Development team about this issue however they tell me that assigning Unique ID's to these web elements is a big no-no. (something to do with globalization of the project when we go to production) Even if they did assign Unique Id's they tell me that they would have to strip them before the project can be sent to production. Which ultimately would render my tests useless in the end...
I now come to Stack Overflow for help, everything I look up online cannot give me an answer, however this does seem to be a valid question between QA and Development departments.
Is there a way to assign Id's to a web element so that a tester using selenium can identify them and yet it will not affect a Developers ability to use that element through an entire project?
Edit:
With the framework that my company uses, I am not actually writing any code in selenium. I save the Xpath to an object and then later in a manual test call that object with a pre-existing method. I can ONLY select Xpaths to be saved in an object.
I'll talk to Dev later to have them explain the big 'no-no' so that I may be able to communicate that with all of you..Thank you for your time and input
For example:
BirthDateSet= someXpath
Click() using {BirthDateSet}
Here are some pictures to help give you a visual
You can simplify your XPathto make it less sensitive to possible changes in DOM:
//div[#class="src-js-components-DateControl-___DateControl__icon___2z6Ak null"][N] # Where N is button index
If this part 2z6Ak of class name is dinamically generated, try:
//div[starts-with(#class, "src-js-components-DateControl-___DateControl__icon___")][N] # Where N is button index
Another way of reaching to the required button using xpath is following:
//*[#id='tenant-details-accordion']/descendant::div[contains(#class, 'DateControl__icon')][1]
Above xpath should be able to select the first occurring button. Similarly, for the second occurring button, the xpath will become:
//*[#id='tenant-details-accordion']/descendant::div[contains(#class, 'DateControl__icon')][2]
Hence, you can continue to replace the predicate([2]) based on occurrence level of the required button on page.
you can ask devs to add attribute to those buttons
so instead of:
<button class="common_class_name">
<button class="common_class_name">
<button class="common_class_name">
for each button you will see
<button class="common_class_name" test-id="uniqueAttributeForButton1">
<button class="common_class_name" test-id="uniqueAttributeForButton2">
<button class="common_class_name" test-id="uniqueAttributeForButton3">
etc
And in your tests you can find those buttons using css selector
e.g. C# code:
var buttonLocator = "[test-id=\"uniqueAttributeForButton1\"]";
WebElement button = driver.FindElement(By.CssSelector(buttonLocator));
if devs doesnt want to add unique IDs or attributes (it's weird why they don't want to do that) you could try something like this:
//return div class 'col-sm-4' which contain text 'Activation Date'
var parentDiv = driver.FindElement(By.XPath("//div[contains(#class, 'col-sm-4') and contains(., 'Activation Date')]"));
//should return div with icon you want e.g. Click
var childElement = parentDiv.FindElement(By.CssSelector(".DateControl__icon"));
childElement.Click();
You can go with the nth approach to find your unique element or with another, that won't solve your real problem which is that your colleague developers aren't cooperating with you. The automated tests are supposed to be (among other things) a service for the developers to know they haven't broken anything as fast as possible, but if they aren't giving any effort, then WHY should you invest in it at all..?
They probably won't even look at the results. Especially when your locators are in the form of div[2]/div[3]... which would break very often and you'll lose their trust in the automation.
I'm no front-end expert but I've seen enterprise products in production with G10N and L10N and other long words, that have id's in their HTML, so if I were you I'd dig deeper to understand why? that big no-no, which sounds very odd to me...
So you asked the wrong question, it should be something like ~ How to add unique id's to the HTML using React in a global web application? and the ones who should be asking it are the developers.
As a side note, as many people tend to think, automation is not mainly about moving manual tests to automated it also finds "bugs" in the communication inside the company. To quote a great blog post on this subject:
Counter-intuitively, the bigger obstacles when developing automation
are either low priority bugs or even things that are not bugs
whatsoever. These obstacles can be symptoms of a bad design, bad
development practices and even symptoms of inefficient communication
patterns in the organization (that are usually caused by the
organizational structure! Conway’s law is a classic example for this).
Good luck!
EDIT:
Thanks for the code.. So if you look at your code, you can see that although what you're after have similar attributes, there are elements in the page that would allow you to identify what you're after. So let's say you want the SET link after Birth Date, then use:
//div[contains(text(),'Birth Date')]/div/a/div
So to reuse this xpath, just replace the text String.format("//div[contains(text(),'%s')]/div/a/div", labelName);
OLD: if you want to temporarily assign the elements an attribute, I believe you can do that through javascript element.setAttribute() which you can run through the executeScript() function.
Don't the buttons have text? Are you saying that the buttons swap places with one another? or don't you want to use the index of the buttons?
I understand you want to select the "Set +" buttons, correct?
If so you can try to find all buttons under the #id="tenant-details-accordion" element with a specific text like that:
//*[#id="tenant-details-accordion"]//*[text()='Set +']

Finding elements in the shadow DOM

Protractor 1.7.0 has introduced a new feature: a new locator by.deepCss which helps to find elements within a shadow DOM.
Which use cases does it cover? When would you want to reach elements in the shadow DOM?
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
To answer your question, here's a related question: "what information does shadow dom provide that looking at raw html does not?"
The following snippet creates a shadom dom (view via chrome or firefox):
<input type="date">
If you click on the arrow, a pop up opens with all the dates, and you can select it.
Now imagine you are building a hotel reservation app and you made a custom shadow dom date picker, where it would black out (and not allow user to select) dates when rooms are unavailable.
Looking at the raw html, you see <input type="date">, and the value/dates that a user selected. However, how would you test that the black out UI is working as intended? For that you would need to examine the shadow dom, where the pop up resides.
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
Doesn't seem so in this website that shows an introduction to shadow DOM. It says that:
Shadow DOM separates content from presentation thereby eliminating naming conflicts and improving code expression.
Shadow DOM mainly helps with separating content to avoid naming conflicts and improving your code expression, making it neater and better (I assume). I am sorry to say that I don't actually use Selenium, so here is a website with plenty more information: http://webcomponents.org/polyfills/shadow-dom/
I hope this helps you!

Need help on selenium hidden elements

I am trying to use selenium to automatically log in the following website:
here is the link https://www.theice.com/
After I click on the log in, a log in screen comes up - I don't know what this is: frame,panel ...
I have not been successful in detecting what elements,properties this screen has through selenium. Thus I am not able to fill in the necessary info through selenium.
Can anyone shed some light on this?
SiKing is correct, here. Nothing too fancy going on with the DOM. Use your favorite DOM inspector and examine the elements and you should be able to identify the locators.
In this case, it looks like the front end devs were thorough and gave major elements 'id' tags. Once you can establish a relationship from an element to it's id, you'll just need to code the selenium commands to interact with them.
While there are a number of good tools for this, I like to recommend FireBug and FirePath addons for Firefox. Similarly to Chrome's inspector, hovering over a DOM element in the inspector will highlight the element itself on the page. FirePath can assist with CSS selectors and XPath if need be.
Without knowing your method of development (code by hand or SeleniumIDE) or you chosen language, I'd simply recommend reading the Selenium docs over at http://docs.seleniumhq.org/docs/03_webdriver.jsp#selenium-webdriver-api-commands-and-operations to get a feel for the means by which elements can be identified and subsequently used.
Incidentally, this site is an example of a good front end design (at least from a cursory glance). Locating elements, once you're familiar with the concepts, should be relatively simple. Play around with it, the best way to learn is by doing (that's why I haven't just given you the solution), you'll get it.
Best of luck.
(Also, I've not meant this message as 'talking down' to you. I'm not familiar with your level of understanding here, so I'm just starting with the basics).
Edit:
It occurred to me, after writing my initial response, that you may encounter an issue with the modal being displayed. After clicking the 'log in' link, you may want to add a wait to your test to ensure enough time for the modal to appear before interacting with it's elements. A simple Thread.sleep() could work here, but I hate recommending that unless it's a last resort situation (we all know sleeps suck, but sometimes it just needs to be done)... Instead, read up on the WebDriverWait class (assuming java) and the ExpectedConditions class. You could pass a locator for the root modal element, or a child thereof into wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("yourLocator")); which will wait until the condition is satisfied (or a timeout occurs) rather than the Thread.sleep() making a hard pause and possibly waiting for a needlessly long amount of time.
The point is, since the modal display isn't instantaneous, WebDriver may choke if it tries to interact with an element that hasn't yet appeared. Using a wait will relieve this problem.