Doing e2e tests, I have to test a stepper form. It is a form with 4 steps. In the first step, some inputs are made, i.e. a username, some numbers, time&date.
In the third step, through some some magic(just doing the tests, not the frontend itself), the inputs of the first step are displayed again, but not as part of the elements that display them. So I cannot do cy.get('foo').contains('bar').
Here is what inspect gives me
Any way I can verify with a test that the data displayed here matches the data inut in the first stepper?
Turns out, there is a thing called 'shadow dom' - which is not enabled by default in Firefox, the browser I used to inspect (and neither in Electron).
Sneaky bastards hide until you turn on the relevant settings.
For electron(v91):
Cogwheel -> show user agent shadow doms.
Firefox(v93):
about:config in adressbar -> search for devtools.inspector.showAllAnonymousContent and turn it to true
You can then work with them using
https://docs.cypress.io/api/commands/shadow
Related
I am very new to TestCafe, (but excited by what I see) so this might be a dumb mistake.
All the examples of TestCafe that I have found, depend on a single URL.
However, I want to test a very familiar sequence:
user makes some choices in page X and clicks submit,
user is shown multiple matching records in page Y, and clicks something in one result,
user sees a detail page Z, with full information for one record
When I try this in TestCafe, my test terminates when control leaves X. It never sees Y.
So, in the last lines of my test, after it submits page X
await t
.click(submitButton);
.. if I look for values which should be in page Y,
await t
.expect(Selector('#back-to-home-page').innerText)
.contains ('Back to Page X');
the Selector cannot find them. It only finds things still in page X.
(I have testcafe v 6.14, but this is not version-specific).
Thank you.
I'm not sure if I understand your question precisely, is page Y a different page that opens? (eg. you click on submit and page Y opens in a new tab / window)
See this for that: https://devexpress.github.io/testcafe/documentation/guides/advanced-guides/multiple-browser-windows.html
Also, judging by the last sample you provided, it might be the case that the element doesn't load fast enough?
Try something like:
await t
.expect(Selector('#back-to-home-page').innerText).contains('Back to Page X', {timeout: 20000})
See if the element is actually there before testcafe expects it.
Thank you for that idea Liviu.
My case is only in a single window, not multiple windows or tabs. Page X and Y are different URLS on the same domain: a form then a search results page. A completely typical flow.
I tried your good suggestion, but it did not work and now I know why.
For reasons unknown so far, the Page X submit button remains disabled even after TestCafe completes the required inputs. It is visible but greyed out. With human entry, this does not happen, only with TestCafe data entry. Some piece of JQuery validation is not getting triggered.
As newbie, before this, I did not know for sure if Testcafe could follow from page X to Page Y in any case, which would be an awful limitation. But I now have proved to myself that works, when I use TestCafe on other sites.
I can't solve the JQuery on my test site, and it is too detailed to post here. But I am happy to close the question.
Thank you guys.
Let us say my test wants to see if a user can see an image on XYZ page. And let's say in normal usage, the user can only go to XYZ page by clicking a link on ABC page (might be the home page).
Now assuming the URL to XYZ page is not static, but maybe depends on the image, and can be generated in the code simply, I have two ways of writing the test:
Generate the URL in test and directly navigate to XYZ, and then check if the image is present.
Go to ABC like a normal user would, click on the link which takes you to XYZ and then check for image
For option 1, I feel like I get more test isolation. If the link on ABC page is not generated correctly or is broken for some other reason, this particular test should not fail, right? That should be the responsibility of some other test?
But for option 2, that is how a real user would do it. He would almost never try to guess the pattern of the URL and then navigate to it directly. And I cannot have a huge test that goes to every link and sees if it is not broken, that would be way too complicated. So this much sacrifice in test isolation is needed.
How should I decide between the two options? Is there a right way? Hopefully the question is not too subjective for stackoverflow.
It depends on what you're wanting to test. If you want to test the buttons or links themselves (ie: you're testing the whole user workflow), click on them just like the user would.
If, on the other hand, clicking these links is just a means to an end and that the real target of the test case is deeper into the app, I think it's perfectly fine to skip directly to the part of the app you're actually testing.
As an End User, best approach will be the Option 2 which also widen the coverage of your test hence you can check:
1. Whether links/ buttons are clickable and not throwing exception.
2. Click on above is navigating to correct page.
Option 1, can be used for test scenario where user doesn't bother about how to reach to the page rather focused only on the opened page contents.
Choosing any of these option is depending on your approach of test coverage and its scope.
I am testing my web application using Selenium. All the form validation in the web application is done by HTML5 and some JS(for safari browser). I want to know what is the proper way to test the form validation.
Currently I am using one approach, i.e Before I filled up a mandatory field I clicked on the submit button. If the page is not refreshed then I assume the form validation working correctly. But I think there should be a better approach to do it. I am unable to find any proper solution. Any suggestion will be highly appreciated.
I also go through this link. But it is not working for me because it is not enough to have required attribute (eg required attribute does not work in older Safari browser).
Rather than checking if the page is refreshed or not, you should instead expect that it is not and that a certain error message or field highlighting or something is applied to the current page. When in an error state, the input fields probably get given an extra class, or an error div/span might be added to the DOM, try checking for that sort of thing
I'm testing (using Selenium) a site containing a slickgrid.
To find the correct field to enter a value, I have to apply a filter, and then double click the field to enter the data.
The problem is, that after applying the filter nine out of ten times Selenium ends up with an exception that the element is no longer attached to the DOM, or is not present in the cache anymore. One out of ten doesn't fail on this point.
I've tried about every bit of advice I can find on this issue, but none has brought any sufficient help. Waiting an looping until the element is present, visible etc. doesn't work.
So: is there a way to have Selenium locate an element in a slickgrid after the page has changed because of a filter action?
Thanks!
I'm using Selenium to ease my testing burden and I have about 1,000 different drop down list combinations (spread across multiple pages and drop down lists) that need to be tested. Basically, what I would like to do is select each <option> inside of a <select>, click the Submit button, select an item (first, second, third, etc.) in the drop down list on the resulting page, click submit, and then go back and select the next item, in sequence. Each time, it should assert that a certain value (related to the drop down list value selected) is present on the final page. Does anybody know if this kind of logic is possible in Selenium?
I'm having a hard time explaining this, so hopefully this pseudo code clears things up
foreach option in select
select option
submit form
foreach option in select
select option
submit form
assert that page contains text that matches selected values
Edit: I have selected values from the drop down list while the recorder is playing, but it seems like the recorder isn't picking up the selected drop down list values. Nor have I been able to figure out how to perform the operation for each <option> in a <select>.
The first question I have is whether or not it's even possible. If it is, could somebody please point me in the right direction to get me started?
Edit 2: I'm not opposed to using another web automated testing utility. If anybody has any recommendations for a free alternative, please feel free to make that recommendation.
What language are using Selenium in? If you're just using Selenium by writing HTML, I'd recommend switching to a programming language and using Selenium RC -- bindings are available for a wide variety of languages, such as Java and Python. In Java, I believe the following would do what you want:
void test(Selenium browser, String startPageUrl,
String firstFormLocator, String firstSelectLocator,
String secondFormLocator, String secondSelectLocator) {
browser.open(startPageUrl);
for (String option : browser.getSelectOptions(firstSelectLocator)) {
browser.open(startPageUrl);
browser.select(firstSelectLocator, "label=" + option);
browser.submit(firstFormLocator); // Or click the submit button
for (String subOption : browser.getSelectOptions(secondSelectLocator) {
browser.open(startPageUrl);
browser.select(firstSelectLocator, "label=" + option);
browser.submit(firstFormLocator); // Or click the submit button
browser.select(secondSelectLocator, "label=" + subOption);
browser.submit(secondFormLocator); // Or click the submit button
// Do your assertions
}
}
}
The code isn't exactly readable, so it might be worth some time abstracting the page away slightly using the Page Object pattern. This also helps make the code more maintainable, for instance when you change the ID of an element, you only need to change it in the page object rather than every test.
Also bear in mind that doing this 1000 times isn't going to be quick. It might be worth seeing if you do similar testing just below the web interface to allow quicker feedback from tests, and then test the web interface is using the lower layer correctly. Also, do you really need 1000 tests? It seems that there's some redundancy in testing here -- is the 1000th test going to fail if the last 999 have passed?