i Would like to know the method on How to capture and display text for auto appearing and disappearing pop-up using cypress.
I had used the window methods for capturing the text and displaying it, but it doesn't capture the message.
The pop-up/alert is designed to appear whenever user generates a report and it automatically disappears after 3 secs.
Please help
Depends on what creates the popup.
For window alert, this question How can we test the alert and text uses stub to capture the call.
It asserts the stub is called with certain text.
const stub = cy.stub()
cy.on ('window:alert', stub)
cy.get('button').contains('Generate Report').click()
.then(() => {
expect(stub).to.be.calledWith('I am an alert box!')
})
From Cypress Window-Alert
If the popup is generated by framework, e.g React the approach is the same as any text on the page.
You might need to use cy.clock() to control the timing, presuming you want to assert the appear/disappear cycle.
Related
I have a pop up window containing a script in its head. And this script should be triggered by click on the window button. But after click on this button the script does not run. Could you suggest the reason?
Steps to reproduce:
Click on a button in the main window.
Child window containing a simple form is open.
Move to the child window, fill in the form fields and click on submit button.
Expected result: The click triggers a script located in the child window head. The script process the form and submit it.
Actual result: an error arises: "submitMyForm is not defined" (reference: submitMyForm() is a method containing in the script mentioned above).
So the problem is that the child window form fields can be populated and form button can be clicked but the script bounded to the button by means of the link <a href="javascript:submitMyForm();"> does not work as the function submitMyForm() is not found. Obviously the reason of the test failure is stubbing the child window which is performed to prevent having 2 windows at the same time. After this the child window is opening in the same browser tab as Cypress is not able to work with 2 windows open in the same time. But in this case the script stops working neither from the test nor by performing the click manually.
Here is a code snippet from the Cypress test:
const pop_url = `/dir1/dir2/file.php?id=${sectionId}`; // Here is a new window URL
cy.window().then( win => {
const stub = cy.stub(win, 'open').as('windowopen');
newSurveySectionListObj.AddNewBtnClick(); // Triggers form opening in the new window
cy.get('#windowopen').should('be.called.with', pop_url);
cy.window().then( $win => {
$win.location.href = pop_url
newSurveySectionListObj.typeDropdownSelect('Matrix'); // works fine
newSurveySectionListObj.modalDescriptionFldType('Cypress test string'); // works fine
newSurveySectionListObj.responseTypeDropdownSelect('Checkbox'); // works fine
cy.get('a[href="javascript:submitMyForm();"]').click(); // Does not work despite the button is clicked. An error "submitMyForm is // not defined" arises
});
});
You are going beyond what Cypress is capable of/designed for.
I would question why you are using a separate window in your app? You will run afoul of pop-up blockers that will prevent the new window being opened anyway. A percentage of users won't be able to work it out.
There are 2 approaches to this:
Use a modal dialog to achieve this (not great on mobile)
Use another route/page to display your form, return to the prev page when done
These have the advantage that they won't break with pop-up blockers, and your Cypress tests will work, as they are still in the same window.
I'm trying to save some data when the popup closes, but I can't find a place to add a listener.
There was an earlier post suggesting this in the background page, but it doesn't work:
chrome.runtime.onConnect.addListener(function (externalPort) {
externalPort.onDisconnect.addListener(function () {
console.log("onDisconnect")
})
console.log("onConnect")
})
Not even the onConnect listener is working.
Any ideas on how to get it to work>
I actually took a different approach. Instead of listening for events, I move the state to the background page. So when the popup opens up it reads the state form the background page and the user can continue where he/she left off.
What is the best option of capturing image after each mouse click in recorded session of Coded UI?
For example, in UIMap.Designer.Cs file I have entered image capturing lines:
Mouse.Click(uIOutagesandSafetyHyperlink, new Point(62, 2));
Image MSOPic1 = UITestControl.Desktop.CaptureImage();
MSOPic1.Save(#"C:\Automation\TestAutomation\web\Recordings\FullSite1\Screenshots\MSO\HomePage_" + DateTime.Now.ToString("ddMMyyyyHHmmss") + ".png");
The above code takes a screenshot but it does not take the current browser's screenshot, just captures another screen where the current browser window does not exist. How can I capture screenshot of the active browser where the test is taking place?
One more question: Does Visual Studio provide an alternative way to capture images during playback? Like through configuration?
One more question: Does Visual Studio provide an alternative way to capture images during playback? Like through configuration?
By default coded ui test should take a screenshot with each action it does.
You can find these screenshots in the html outputs for your tests.
See: https://msdn.microsoft.com/en-us/library/jj159363.aspx
If in any case it is not enabled for your tests you have to set:
Playback.PlaybackSettings.LoggerOverrideState = HtmlLoggerState.AllActionSnapshot;
If you want to have this setting in all tests and for all actions call it in the [TestInitialize()] method of each test you want to apply it to.
Like so:
[TestInitialize()]
public void MyTestInitialize()
{
Playback.PlaybackSettings.LoggerOverrideState = HtmlLoggerState.AllActionSnapshot;
}
The UITestControl class has a CaptureImage method. To get an image of the current browser, find its UITestControl object (which may be derived from that) and call its CaptureImage method.
Please do not edit the uimap.designer.cs file as it is an auto-generated file and your edits may be lost. See this answer.
Context: In my rspec (using Ruby and Capybara)
I click on a link to test an action in my app: adding a branch to my app.
A modal window opens, where I select the branch, and then I click a "submit" button to add the branch to my app. After clicking "submit" the modal window is closed.
The rspecs continues by clicking "Save" in the main screen, to save the state of the application (and effectively saving adding the branch).
Problem: The rspec is failing because (seemingly) it is trying to click the "Save" button on the main screen while the modal window that is used to select the branch is still present. The test doesn't complain that it can't find the "Save" button component, but that it can't be clicked.
The error in the log is:
[...]Save</button> is not clickable at point (692, 23). Other element would receive the click[...]
A gotcha: this rspec passes correctly on some environments, like when it is run against my local server, but it fails when it is executed by our automation server. Thus, this test has been tagged as "flaky".
Potential solutions: Things we have tried so far:
Play around our "clicks configuration", making sure we are on "ready state" and that the modal window is gone. We failed with this, since we kept hitting the same error.
Implement a "wait". We added a loop to sleep for a bit while the modal window seemed to exist
XYZ.add_new_branch_name(#branch_name)
while Utilities.element_visible?(:xpath, myElement)
sleep(0.5)
end
XYZ.save
The while condition checks if the "submit" button of the modal window exists. The element_visible function uses
find(method,element).visible?
but I'm not sure if find should already take into account that the button may exist and be visible but not be clickable.
Since this still fails, in spite of all our effort to make sure that the modal is gone before we attempt to click on the "save" button, I want tot ask:
Is there a proper way to detect if an element behind a modal window is clickable or not using rspecs?
find only cares about "visibility", not "clickability" (and different drivers may have slightly different interpretations of "visibility"). The reason for the flakiness you're seeing is most likely speed of the machine running the tests which affects the timing of the modal animating away. The best way to solve this issue is to disable animations in the test mode (how you do that is dependent on exactly what library and/or CSS you're using for the animations). The other way is to do as you're doing - checking that the modal has disappeared before clicking the 'Save' button, however you should just be using the Capybara provided methods (which include waiting/retrying behavior) rather than writing your own loop for that.
expect(page).not_to have_css('css selector of the modal') # RSpec version
assert_no_css('css selector of the modal') # minitest version
After looking at the mouse position from your error, one other potential issue you may be having is with screen size and scrolling. If the page requires to be scrolled to get to the 'Save' button and (692, 23) would put the button behind a fixed header (you should be able to verify that by taking a screenshot before the button click attempt) then it may not be possible for whatever driver you're using to click the button. In that case you'd need to use execute_script to scroll the page to a different location so the button is not covered on the page and/or increase the "browser" size so scrolling isn't necessary in the test.
I had a similar problem and solved it by writing my own click_on_with_wait helper function:
def click_on_with_wait(text, wait_time: Capybara.default_max_wait_time)
success = false
(wait_time * 10).round.times do
click_on text
success = true
break
rescue Selenium::WebDriver::Error::WebDriverError
sleep(0.1)
end
# Try clicking one last time, so that the error will get raised if it still doesn't work
click_on text unless success
end
This will try to click on the element. If it's still hidden by the modal, the function will wait 100ms and then try again, until the given wait_time is reached.
Using Rails, I put it in system_spec_helpers.rb so that I can simply replace click_on 'Submit Form' with click_on_with_wait 'Submit Form'.
I am writing a plugin that uses a dialog box.
I notice that clicking the toolbar button to open the dialog box fires a change event on the editor. Is there anyway to disable this event when opening the dialog box?
The plugin modifies the content using setAttribute(), removeAttribute(), and removeStyles(). Is there anyway to have calls to these methods fire a change event?
After more investigation, I discovered 2 issues (which I think relates to using YUI's App Framework), which might be the cause of the unexpected behaviour.
To reproduce: http://jsfiddle.net/c3tqk/
Problem 1:
1. Select part of the first paragraph (text) and click the Edit Link button.
2. Select part of the second paragraph (link) and click the Edit Link button. Check the console and notice a change event is fired.
Problem 2:
1. Select ex in the first paragraph and click the Bold button.
2. Deselect and select the x in the first paragraph and click the Bold button. Notice that the change event is fired twice.
You can always fire an event manually though it's not usually recommended. Use CKEDITOR.event.fire:
element.setAttribute( 'foo', 'bar' );
editor.fire( 'change' );
A better idea is to use editor#saveSnapshot event, which creates undo snapshots (your change becomes officially undoable, that's pretty cool) and fires editor#change automatically, if needed:
element.setAttribute( 'foo', 'bar' );
editor.fire( 'saveSnapshot' );
You can also interrupt existing events as they get fired and make sure no other listeners are called. Simply use CKEDITOR.event.on listener with low priority.
editor.on( 'change', function( evt ) {
if ( some condition ) {
evt.stop();
// ...or...
evt.cancel();
}
}, editor, null, -999 ); // by default listeners have priority=10
See CKEDITOR.eventInfo.stop and CKEDITOR.eventInfo.cancel. They're slightly different.
It might be tricky to get why the event is fired as you click to open the dialog box (and to create the right rule), but it feels quite possible. I couldn't reproduce it though (tried latest Chrome and FF); change was fired only when typing or executing commands (like Bold, Link, etc.). If you provided some extra info about your setup (versions of CKEditor and the browser, editor config and the name of the dialog), it would be much easier to debug.