How do you plan to handle the selenium replaying? Does it currently just record the x/y position of the cursor events, because if so I guess it needs playback on a browser window of the same dimensions.
I guess it may be possible to have some adaptors for cursor events which can process the clicked element for a framework, i.e. for reactJS it could pick out the classname and use that as the click target for playback in a screen size independent way.
My gut instinct was that this would mean lots of re-recording tests every time you make a change - but really that's much the case with screenshot testing or any e2e testing already! Great work!
Mouse position is irrelevant in selenium cases right now.
Right now I'm trying to create basic case in which recorded events would be reproduced in correct sequence, reproducing what we've done on page.
The down side is - what is collected is xpath (just because it is shorter than dom selector), xpath is absolutely vulnerable to changes so your tests will fail after F5 (in case of generated ID's whatsoever).
Is there an example that shows how to actually implement in a page? I'm looking through the github code and it's not immediately obvious how to embed the recorder/replay functionality.
I would be really interested to be able to use the playback part of this for unit testing. I have code that can click buttons, but it would be great to have a library I could just load inside a page and then play back a series of events.
I am poking through the source... seems like it should be pretty easy to programmatically build a stream of events to load, but I can't quite find the code that actually plays them back?
You can find `play` function in it. `play` function calls for `eventsScheduler` that does replay part by calling actions (events) on saved objects in pre-saved time (ie. time you moved your mouse and clicked here and there).
If you have any further questions email me. I've attached my email to my hn profile.
Is this meant as an alternative to Inspectlet? If that's the case, awesome. Their tech is very powerful and useful but so, so expensive for the layman.
I know the community here is very anti-tracking, but I really do like using trackers like this to improve the UX, understand what features people use and how they use them, etc.
FullStory is a vastly better offering than Inspectlet IMO. I rarely see a feature done as poorly as Inspectlet's search/filtering is. Just absolutely terrible. Don't know if I'm the only one on that, or what. If this is half as good though it may be a replacement for both.
I don't have any experience with FullStory or Inspectlet, haven't heard of.
Whole idea about this tool is just attempt to automate `some` of tester's jobs, in example - save scenario, run it again some time later, ideally automate it with selenium/jasmine.
Hey, can you explain how your heatmap handles scrolling? I expect a heatmap to show what elements of a page were interacted with a lot, if scrolling isn't handled correctly, it might look that the user was interacting with another part of the page than he actually was.
I saw something really nice with Elm elm-lang.org where one could record the user behavior, Push it to Google Firebase and replay it on a developer machine for debugging.
How do you plan to handle the selenium replaying? Does it currently just record the x/y position of the cursor events, because if so I guess it needs playback on a browser window of the same dimensions.
I guess it may be possible to have some adaptors for cursor events which can process the clicked element for a framework, i.e. for reactJS it could pick out the classname and use that as the click target for playback in a screen size independent way.
My gut instinct was that this would mean lots of re-recording tests every time you make a change - but really that's much the case with screenshot testing or any e2e testing already! Great work!