- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago - last edited 3 hours ago
I struggled a bit with this and I saw some conflicting info so I thought I'd post what I found in case someone else finds it handy.
In Zurich, there are new Custom UI ATF steps. I wanted to test a new related list button that opens a modal, allows users to select records by checking the checkboxes and then, when another button is clicked, it creates a risk record against the parent.
Step 1, as usual, is to create and impersonate a user. Step 2 is to create a project record. Nice and easy.
Step 3 is to open that project making sure that you select the relevant workspace in the Form UI field (see screenshot).
Step 4 is where we use the "Click Component (Custom UI)" ATF step. When you select this it will invite you to retrieve the page components. Essentially, it runs the test to the point where you are, using a Test Runner and then, goes through the page collecting all of the possible interactive components on the visible page.
In my case, I wanted to navigate to a related list that wasn't visible and so I need to click the "More" drop down.
And then, select the related list name from the list of related lists that aren't currently visible. In this case, that's "Risks". So, my ATF steps are Click Component (Custom UI) (for "More") and then again to click "Risks" (see screenshot).
If you run the test now, you will that the risks related list is visible in the Test Runner.
Step 7 is another Custom UI step that asserts that text is visible on the page. I found that this was required because sometimes, the page itself was slightly slower than the test and so when it moved onto the next step (i.e. "click the button"), the button wasn't actually there yet. So, I added a text assert to confirm that the text from the button is visible and gave it a 20 second timeout.
Step 8 is "Click Component (Custom UI)" using the same process of gathering the components and selecting the right one.
The modal opens. Next is another text assert for the same reason as above to ensure the page as caught up and we can see the modal title before moving on.
This is where I got a bit stuck. Step 10. I read a few relatively recent posts that told me that it wasn't possible to interact with a checkbox via ATF but I found one place that told me to use the "Set Component Values (Custom UI)". Using the same method of gathering the possible interactive components and then selecting the one I want, I set the value of the checkbox to true.
The declarative action on the modal is called "Create Risks" but there is a count on the button title and so, step 10 causes the text on the button to change to "Create Risks ( 1)". That is obviously different and so the test can't see the button if you've told it to look for "Create Risks". It needs to gather components again after the checkbox has been selected so it can find "Create Risks ( 1)".
So, step 11 is to simply click that button once it's been found. After that, we add a new negative assertion on the text of the modal name to confirm that modal has closed and then, we do a simply query to confirm that there is a risk with the project we created in step 2 as the Task.
For some reason I wasn't able to paste screenshots in. Hopefully the attachments are accessible.
There is a test called "Test Page" in the Configurable Workspace category. Selecting this and pasting the URL in will open a nifty page that shows you the page and lists all the components down the side. It's a good way to identify the names of the components that you're interested in because they might have "backend" type names and there could be literally hundreds of them to look through.
You can even create a test step right from that view.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
