Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thinking of a new paradigm for recording #31

Open
chenglou opened this issue Jan 24, 2014 · 10 comments
Open

Thinking of a new paradigm for recording #31

chenglou opened this issue Jan 24, 2014 · 10 comments

Comments

@chenglou
Copy link
Owner

It'd be really great if the user doesn't have to juggle between the terminal and the browser. The only way to do that is to have the screenshot taking action happen in the browser. Two options:

  1. Assign a keyboard shortcut. Could introduce a fast screen flash to indicate screen capturing.
  2. Automatically take screenshot at each relevant event. Stuff like key entering could get a delay before capturing screenshot.

Both open doors to the possibility of removing the distinction between live replay and ordinary chained replay, since without the windows switching delay the whole testing can be replayed live without too much useless time gaps. Reducing the remaining time gaps can be done by Huxley itself when relevant, i.e. between keystrokes.

@jhnns
Copy link

jhnns commented Apr 22, 2014

Sounds interesting. Juggling between the terminal and the browser is really distracting and annoying when I record something.

Automatically take screenshot at each relevant event. Stuff like key entering could get a delay before capturing screenshot.

I'm not sure about this. I think that it is more flexible if I'm able to specify when a screenshot has to be taken. I end up editing the delays manually anyway.

@chenglou
Copy link
Owner Author

I've written down more thoughts locally. Option 2 is probably not doable realistically speaking. It's a cool idea though.
What makes you edit the delay?

@jhnns
Copy link

jhnns commented Apr 22, 2014

Some delays are too short. It worked while recording, but they're too short for automated testing since we don't want false positives. And others are far too long because I needed to switch between the terminal and the window (and I needed some time to think about which button to press, maybe I need a new cpu 😄).

@chenglou
Copy link
Owner Author

Just to clarify: the short and long delays are all intentionally done by you using l right?
There's no weird race condition when replaying without live playback on non-animated tests?

@jhnns
Copy link

jhnns commented Apr 22, 2014

Yep, I'm always pressing the l button. I'm still experimenting, but it seems like my tests are working fine. I haven't used the live playback option, just starting huxley with hux.

@chenglou
Copy link
Owner Author

Just so that we're on the same page: live playback is l. If you don't have any transition or ajax wait, you don't need l btw, just normal enter.

@jhnns
Copy link

jhnns commented Apr 22, 2014

Yes, I know. I'm working with l because I have transitions on my html elements. I thought that this might be a problem if the screenshot is taken immediately after the user interaction.

@chenglou
Copy link
Owner Author

Ah, alright. Yeah this is probably never gonna an exact timing because of selenium's own delays.
Anyways, I guess realistically I'll go with the first path, if I ever do.

@jhnns
Copy link

jhnns commented Apr 23, 2014

Is selenium adding a delay between actions? If yes, is it just a rigid default value or determined by some event?

@chenglou
Copy link
Owner Author

I think it's just slow lol. It's faster for the chome driver. I chain up the calls without delay (unless there's an explicit pause).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants