I am trying to switch frames in MS Dynamics 365 system using Selenium WebDriver. I will explain one of the issues below. Here is the html element code:
element code here
Usually, i used to use id=contentIFrame0 or 1, and the frames were switching fine. The problem is, that MS Dynamics generates those iframes dynamicly, usually contains max 3 iframes(contentIFrame0, contentIFrame1, contentIFrame2), but the fact is that you never know they will be 2 or 1 on the page and why, so if you use today one of them directly - tommorow your tests will fail because of the changes.
It seems like I have to switch all the time to the last frame, but it works randomly, because sometimes there is the first one contains element and another one scripts. Other thing i tried to do, is to switch to one iframe which has attributes: style = visibility: visible(before that, i tried to print in console how many visible frames driver sees - but written all the time 0). Also, if i try to print in the console how many iframes there are on the page - the counter is 2, but I can see 3.
If there is anyone who tried to automate MS Dynamics 365 and had the same problem?
I have discribed probably all cases, maybe you will notice the logics and difference.
I am not sure if this works in your case but please give it a try.
If you know one of the elements in the frame which you are trying to switch then use the css selector or xpath
driver.switchTo().frame(driver.findElement(By.cssSelector("iframe[title='test']")));
It very hard to test in this fashion as Microsoft doesn't guarantee that the objects being rendered will stay the same. It may be 3 frames today, but in the next version the dev team may introduce more or less, working with the DOM directly is no longer supported.
I would highly recommend the following framework for testing Dynamics: https://github.com/Microsoft/EasyRepro
It will help elevate your testing up one level, it’s introducing a level of abstraction so as to minimize the need to work with HTML directly by isolating all that low-level work in the framework code.
Here is a great post about EasyRepro: http://www.itaintboring.com/dynamics-crm/easy-repro-what-is-it/
Goodluck
This xpath finds the main pane reliably
//iframe[contains(contains(#id,'contentIFrame') and contains(#style,'visible')]
Note: not applicable to Dynamics 365 Unified Interface, it has completely different DOM.
Related
I'm currently in the process of setting up Cypress for my project. Currently we're only using testing library for frontend tests. And reading the Cypress documentation has gotten me a bit confused as the two libraries seem to have opposite philosophies in regards to how you're supposed to query for elements.
Testing library basically says test what the user can see/touch and only use data-testid if all else fails. Cypress on the other hand states that best practice is that you should query elements by data-testid / data-cy attributes.
I feel conflicted between the two approaches. I get the point about we should test what the user actually sees (testing library). But I do also get that those things often change (cypress) and we need to spend time updating tests whenever we make small changes (i.e "Ok" -> "Done"). And when testing with data-cy attributes, are we not also ignoring accessibility / screen readers?
What are your thoughts on this?
React Testing library(RTL) is specifically made to write tests from a user perspective. From their Guiding Principles:
The more your tests resemble the way your software is used, the more confidence they can give you.
Meaning, RTL wants you to use accessibility queries like getByRole and only fallback to getByTestId for cases where you can't match by role or text, or it doesn't make sense (e.g. the text is dynamic).
However, thanks to the render method allowing us to specify props (compared to Cypress), we have much more flexibility and may entirely omit dynamic text.
Cypress, on the other hand, runs with all dependencies. In case of dynamic content from a C.M.S or multi-language application, things are not that easy using getByRole("heading", {name: /welcome/i }). In this case, the recommendation of testId's make sense.
My personal recommendation is to use accessibility query selectors in both Cypress and RTL, unless the text is dynamic. Then testId's in Cypress and a combination of testId's & accessibility query selectors provide the best solution.
It should also be noted that Playwright and Cypress test-generator tools select by accessibility query selectors.
I thought a lot for a few days before answering this question and I even got to do some tests, and after that time I came to the conclusion that the Cypress approach is the best.
The main reason that led me to this answer was that when the testing library says that we should test what the user actually sees, it is already applicable in Cypress even when we use a data-testid, because let's suppose you have a button that exists in the DOM, but it is not visible when you select this button, with the data-testid when you try to click in this button Cypress will return an error saying that the button is not visible and if you really want to do this action you must apply force:true. The same happens if the button is not clickable or if there is another element in front of the button.
Cypress already checks by default in click and type actions if the element:
element is into view
it is visible
it is not disabled
it is not detached
it is not readonly
it is not animating
it is not covered
fire the event at a
descendent
Also if you fetch the element by text, placeholder, or class, this does not guarantee that the element is actually visible to the user, as the element can be in the DOM and not be visible to the user for various reasons.
So the best way to make tests easier to maintain, easier to read, and avoid flaky tests is to use the data-testid and whenever possible or necessary combine the location of the element with an assertion to ensure that the element is visible. Example:
cy.get('[data-testid="button"]').should('be.visible')
I hope I had contributed to the discussion and would love to hear other people's points of view.
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.
Am trying to capture a element (delete button in gmail) which has variable xpath.
The xpath is something like this-
//*[#id=':rr']/div/div[4]/div[1]/div[1]/div[1]/div/div/div[2]/div[3]
can somebody kindly help?
No, this is where the IDE falls behind and it's for good reason. It, along with other 'XPath-ified' (e.g using the 'XPath' right-click option in Firebug) tools will only take a guess at where something is located in the DOM.
In that, I mean it's going to walk down the tree and see where it is, in relation to the other elements, i.e it'll walk down one set of tr elements, and know there are 7 of them, therefore it'll know that the first one can be accessed using [1], then the next one can be accessed using [2] etc etc...
It doesn't, or really can't, know what is unique enough for you to use. That's why it's down to you to figure it out.
As for Gmail specifically, I would suggest you either fall back to Gmail's basic mode - so the markup will be easier to deal with or stop completely and use a particular set of API's in whatever language you are using to deal direct with the mailboxes in that account.
Though, if you do this, you'll need to dump the IDE altogether - essentially this is beyond the IDE and is a logical thing you need to decide yourself. The IDE is not designed for this.
Though, a tip would be see what's near the delete button. Is there a static element, that has the same attributes all the time, near it? You can get that element, and walk through to the DOM to your 'delete button'.
We have plans to use Jubula to test the functionality of our web application but after evaluating Jubula we have run into a problem. We can't make Jubula click fields which have a varying id (generated).
I know that Jubula uses Selenium inside so using XPATH for maching elements in the DOM should not be a problem. Do you know about any Jubula hack or alternative / derivative which makes this possible?
I think it is not that easy to use XPATH directly with Jubula. However, Jubula uses XPATH internally to address components in a web page.
Your problem might be solvable by just ignoring the id's and using context and hierarchy for component mapping. To do this just try setting the names weight to zero in the object mapping editor (on the Configuration View). You may have to adjust the Threshold slider as well.
I've read the documentation and understand that this is to be expected:
Scripts are injected into the top-level page and any children with HTML sources, such as iframes. Do not assume that there is only one instance of your script per browser tab.
I'm wondering, though:
Other than iframes, what other elements have "HTML sources" (images? objects?)? The term "HTML sources" is uncomfortably vague to my ears.
Is there any way to detect which element is executing the script?
I've filtered out iframes by determining that window === window.top, as recommended, but other elements are still executing the script and it's executing a lot more than I'd like.
Thanks.
It's really my own fault that I'm answering my own question because I didn't really provide enough information in my question. In my defense, I didn't know at the time that I was providing too little information.
Anyway, while traveling down the road to a solution for this, I asked a question on Apple's dev forum and included the following bit of key info:
Everything in the script occurs on the beforeload event of the document (or was supposed to).
What I learned was that the beforeload event only fires for subresources within the document. Not for the document (or window) itself. I removed the event handler and made sure that the script was applied as a start script (it was). I'd already applied the test for the window as top window so I was covered. Now my injection script only fires once.
Other HTML sources may be frames or object tags (with HTML contents). I don't think it can be anything else. However, to the extent of my knowledge, they should also be filtered off with window === window.top. Try console.loging the document.location variable to see which URL runs your injected script, and maybe you can find what loads them.