In short, I have a table row with an onclick event. I am getting this via
const row = screen.getByRole('row', { name: /My row/i })
await userEvent.click(row)
This does not trigger the event handler. However, if I do:
const row = screen.getByRole('row', { name: /My row/i })
fireEvent.click(row)
This works fine.
I know userEvent uses more events to simulate a row click, but the event handler works fine in the live application too. Are there any reasons why userEvent might not work?
Like most very strange things, the problem lied elsewhere. But for documentation purposes, this was due to the app rerendering while doing my assertions. What would happen was this:
App renders, making a bunch of API calls
My API call for my test finishes, say, get user
findByText('My User') passes and gets me my DOM element
Another API call finishes, re-rendering the component to show this data
The result of findByText is no longer the current active DOM element
click fires
As its no longer in the document, there's nothing to click/fire an event
I changed my previous lines to check for ALL data loads before grabbing my row and it seems to consistently be working. This means I have to assert things unrelated to my tests, but that may be due to my app having poor UX with things popping in as they load?
Either way, I'm not 100% confident this is the reason, but if
userEvent.click is not firing events, or
toBeInTheDocument is failing, even if findBy worked
It may be due to your app rerendering after you've asserted everything has loaded. Hope I can save someone else 3 days of suffering like I had to to find that simple fact...
Related
I'm creating a SwiftUI multiplatform app in XCode and I have a section of my code that hangs. I want to update the user so they know what's happening and are willing to wait. I originally planned to have an alert with text that changed and then planned to have a Text element that updated. In both cases this isn't shown until after the code executes and as such only shows the final message (normally the success done message unless an error made it end sooner).
Is there anyway I can have a visible message to the user through an alert or SwiftUI element that is updated right away and thus will be helpful?
The fact that the alert isn't even shown until after the code executes is bad and incorrect. This suggests that you are doing something lengthy on the main thread, and that is an absolute no-no. You are freezing the interface and you risk the WatchDog process crashing your app before the user's very eyes. If something takes time, do it in the background.
I am facing issue with callbacks. I have 3 drop downs, one scattermap , one table and one slider on the screen and they all need to work in tandem and i have 5 call backs. When i execute the application all my callbacks associated with these controls execute in random order. After that when i click on scattermap it may or may not work. Say we assume it worked. Then i can navigate all around without any hassle. Then if i execute the application then click on the scattermap then as i mentioned it may or may not work. Say suppose it didn't work this time. If so is the case it will not work at all no matter what i do and simulaneously one specific dropdown also becomes dysfunctional. However if click any of the other two drop downs then evrything will start functioning as normal.
I have digged really deep into this and figured out that this has nothing to do with my code. The underlying issue is that when the click doesn't work the reason the reason behind that is the callback isn't getting triggered. I found out this by applying some debugging techniques and i am 100% sure the callback is not firing. Can anyone help me resolve/understand this please.
I am using cdp (https://github.com/mafredri/cdp) in order to use devtools protocol to generate a pdf of a page. But first I need to know when the page is completely loaded. I found that the networkIdle event can help me to know when this occurs. But, I have troubles because the networkIdle event sometimes fired twice. Then I need to know when this one is fired
There are two parts for what you're looking for.
First of all, the reason the event is fired twice. When a new tab (target) is created, the first page it loads is about:blank. You get lifecycle events for this page as well. The second time the load event is fired is the one you're looking for (if you're using Page.lifecycleEvent).
Now, to handle the second matter - there are also other events you can use. The basic one for page loading is Page.loadEventFired, which, as far as I recall, will only be fired for the actual page (but I could be wrong about this one).
Important note: If you're using lifecycle events, they are fired for each frame separately, meaning that the main frame might finish loading before the sub frames are loaded. Page.loadEventFired has a different behavior and waits for all frames to fire their load event.
Here is a good article on the page lifecycle api.
Another possible solution could be:
document.onreadystatechange = function () {
if (document.readyState === 'complete') {
run the screenshot code...
}
}
I've just started using ag-grid with vue, and noticed that sometimes onGridReady fires first, and sometimes onFirstDataRendered fires first. I was wondering if there was an event guaranteed to fire before both of those, so that I could set this.gridApi = grid.api once. (I'm currently setting it at the beginning of both as a workaround).
Update: this only seems to happen when the vue component containing the grid is initialized after page load (via a v:if), and not when it is visible on page load.
Actually you missed something I suppose, cuz onFirstDataRendered couldn't be executed before gridReady - cuz only after initialization (exact grid-ready event) - the grid itself would be ready to proceed.
Here is a hierarchy from ag-grid doc, which sais :
GridReadyEvent - will be executed very first.
The page I'm using watir-webdriver on will often not load completely for maybe like a minute because of the many external scripts I'm loading/using. This of course means that I have to wait needlessly for a minute when I could have performed the checks I wanted to in 10 seconds after the browser I'm controlling (Firefox) started loading the page.
I noticed that even though my target elements become immediately available in the page, the browser.div(:id => 'some_id').present? method hangs until the page is fully loaded. I noticed that if I press on the stop button in the browser window, watir will immediately continue successfully with my tests (the present? method un-hangs). Is there a way to avoid this behavior of the present? method and be able to tell that my target elements are present without having to wait for the page to fully load?
I've experienced this issue before as well. The method I employed, which rides on the idea you mentioned about hitting the stop button, is as follows:
begin
browser.wait_until{browser.div(:id => 'some_id').present?}
rescue
browser.send_keys :escape
end
expect(browser.div(:id=> 'some_id').present?).to be true
This, by default, gives that div 30 seconds to appear (you can insert a smaller value then 30 if you prefer), otherwise it causes watir to hit 'escape' which will stop any remaining background page loading and resume the test.
.present?
As I understand it checks to see if an element exists AND is visible.
What I would suggest you try, is
.exists?
This will simply check that the element exists, and doesnt care if its visible or not.
Just for reference, there is also a
.visible?
Which just makes sure the item is visible, though I dont ever use that one.